Making a variable addressable in GIMPLE
Hi all,
I'm trying to inject code that uses variable addresses into the first
mudflap pass. These variables are not natively addressable in the
program itself.
The problem is that the first mudflap pass takes place at the GIMPLE
level, at which point all variables have their
addressable/non-addressable attributes set, which forbids me to build an
ADDR_EXPR node for a non-addressable pointer variable ("invalid operand
to unary & operator" error).
Is there a way to change this attribute at the GIMPLE level, or do I
need to move my pass back a few notches, before gimplification?
Thanks,
Yoav Etsion
Re: Reconsidering gcjx
Hear, hear!
I think using ecj as a gcj front end sounds like a terrific idea!
Kind regards,
Thomas Hallgren
Tom Tromey wrote:
Now that the GPL v3 looks as though it may be EPL-compatible, the time
has come to reconsider using the Eclipse java compiler ("ecj") as our
primary gcj front end. This has both political and technical
ramifications, I discuss them below.
Steering committee members, please read through if you would. I think
this requires some resolution at the SC/FSF level.
First, a brief note on gcjx. I had intended gcjx to serve not only as
a cleanly written replacement for the current gcj, but also as a model
for how GCC front ends should be written in the future; in particular
I think writing it as a library and separating out the tree-generating
code from the bulk of the compiler remain good ideas. I enjoyed, and
continue to enjoy, the writing of gcjx. However, in this case I think
that pleasure must give way to the greater needs of efficiency and
cross-community cooperation.
Motivation.
The motivation for this investigation is simple: sharing code is
preferable to working in isolation. In particular this change would
let us offload much of the front end maintenance onto a different
group.
Ecj has a good front end (much better than the current gcj) and decent
bytecode generation. It is fully 1.5-compliant and, apparently, is
tested against the TCK by the upstream maintainers (us gcj developers
don't have TCK access). It also has some improvements for 1.6 (stack
maps). Upstream is very active.
gcjx by comparison is unfinished and really has just a single
full-time developer, me.
Technical approach.
Historically we've wanted to have a 'native' java-source-code-reading
compiler, that is, one which parses java sources and converts them
directly to trees. From what I can remember this was based on 3
things:
* In the past the compiler handled loops built with LOOP_EXPR better
than it handled loops built "by hand" out of GOTO_EXPRs. My
understanding is that this has changed since tree-ssa. The issue
here was that we made no attempt to rebuild a LOOP_EXPR from java
bytecode.
* The .java front end could do a "constant array" optimization. This
optimization has not worked for quite some time (there's a PR). In
any case we could implement this for bytecode if it matters.
* The .java front end could more efficiently handle class literals.
With the new 1.5 'ldc' bytecode extension, this is no longer a
problem.
In other words, as far as I can remember, our old reasons for wanting
this are obsolete.
I think our technical approach should be to have ecj emit class files,
which would then be compiled by jc1. In particular I think we could
change ecj to emit a single .jar file. This has a few benefits: it
would give -save-temps meaning for gcj, it would let us more easily
drop ecj into the existing specs mechanism, and it would require very
few changes to the upstream compiler.
An alternative approach would be to directly link ecj to the gcc back
end. However, this looks like significantly more work, requiring much
more hacking on the internals of the upstream compiler. I suspect
that this won't be worth the effort.
In my preferred approach we would simply delete a portion of the
existing gcj and turn jc1 into a purely bytecode-based compiler. Then
we would proceed to augment it with all the bits needed for proper 1.5
support.
ecj is written in java. This will complicate the bootstrap process.
However, the situation will not be quite as severe as the Ada
situation, in that it ought to be possible to bootstrap gcj using any
java runtime, including mini ones such as JamVM -- at least, assuming
that the suggested implementation route is taken.
Politics.
I don't know whether the FSF or the GCC SC would let us import ecj,
even assuming it is actually GPL compatible. SC members, please
discuss.
We don't know how upstream would react. I think this is a fairly
minor risk.
It is unclear to me whether we must even rely on GPL v3 if we went
with the separate-ecj route. Any comments here? In the
exec-via-specs approach we're invoking ecj as a separate executable,
much the same way we exec 'as' or 'ld'. Comments on this from
license-oriented folks would be appreciated.
Summary.
I think this would be the most efficient way to achieve 1.5 language
compatibility for gcj, and it would also make future language changes
less expensive. Given the scope of the entire gcj project, especially
when the scarcity of resource devoted to it are taken into account,
this is significant enough to warrant the change.
Tom
Re: Reconsidering gcjx
Tom Tromey writes: > Historically we've wanted to have a 'native' java-source-code-reading > compiler, that is, one which parses java sources and converts them > directly to trees. From what I can remember this was based on 3 > things: > > * In the past the compiler handled loops built with LOOP_EXPR better > than it handled loops built "by hand" out of GOTO_EXPRs. My > understanding is that this has changed since tree-ssa. The issue > here was that we made no attempt to rebuild a LOOP_EXPR from java > bytecode. > > * The .java front end could do a "constant array" optimization. This > optimization has not worked for quite some time (there's a PR). In > any case we could implement this for bytecode if it matters. > > * The .java front end could more efficiently handle class literals. > With the new 1.5 'ldc' bytecode extension, this is no longer a > problem. > > In other words, as far as I can remember, our old reasons for wanting > this are obsolete. True, but there is still some information lost when going via the .class format. Per mentions debugging information, but there are some other problems. In particular, the type system and the rules for exception regions are different. Also, a "slot" in the .class format doesn't necessarily correspond to a variable in the source language. We work around all of this fairly sccessfully, but from an engineering POV it's something of a kludge. > I think our technical approach should be to have ecj emit class files, > which would then be compiled by jc1. In particular I think we could > change ecj to emit a single .jar file. This has a few benefits: it > would give -save-temps meaning for gcj, it would let us more easily > drop ecj into the existing specs mechanism, and it would require very > few changes to the upstream compiler. I think that from a maintenance point of view this would be a PITA. Also, as Per mentioned we'd need to extend the .class file format in a non-standard way to get full debugging information. In particular, .class files don't contain the full pathnames to source files. If we were starting from scratch it would be good to start with ecj. But we aren't starting from scratch, and it looks to me as though gcjx has the potential to be the best long-term route. Andrew.
Generic vector extensions (execute/simd-2.c)?
Ok... can someone explain to me how the generic vector extension is supposed to work? I've added a few V2HImode operations to the Blackfin backend (in a 3.4-based compiler), and now I'm getting aborts all over the place because the compiler is trying to make V8HImode registers for operations on typedef short __attribute__((vector_size (16))) vecint; Is this something that just isn't supposed to work in 3.4? Current mainline behaves differently and gives me TImode registers (which I'd rather prefer not to have to deal with either, though, but the compiler appears able to cope with them so far). Bernd
Re: Reconsidering gcjx
Andrew Haley wrote: I think that from a maintenance point of view this would be a PITA. Also, as Per mentioned we'd need to extend the .class file format in a non-standard way to get full debugging information. In particular, .class files don't contain the full pathnames to source files. The "SourceDebugExtension" attribute specified by JSR-45 (http://jcp.org/en/jsr/detail?id=45) provides one way to provide full pathnames. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Making a variable addressable in GIMPLE
Yoav Etsion wrote:
> The problem is that the first mudflap pass takes place at the GIMPLE
> level, at which point all variables have their
> addressable/non-addressable attributes set, which forbids me to build an
> ADDR_EXPR node for a non-addressable pointer variable ("invalid operand
> to unary & operator" error).
>
Call build_addr() to create the ADDR_EXPR. It will set the
TREE_ADDRESSABLE bit on the variable and set some attributes on the
ADDR_EXPR itself.
That message suggest that you may be trying to build the address of a
non-decl, though. Show me the code and an example of your transformation?
Re: Reconsidering gcjx
On Friday 27 January 2006 09:10, Paolo Bonzini wrote: > How big would the mini Java-runtime be? A bytecode-interpreter, with > only support for two or three packages, using a simple Baker or > mark'n'sweep GC, could be done in 10,000 lines of C code or maybe less. JamVM is pretty small, I doubt it would be worth the effort of trying to make something smaller. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.kiffer.be/k/ [EMAIL PROTECTED] +32 3 216 0369 See us at Embedded World 2006 in Nuernberg, 14--16 Feb. 2006. We're on the DSP Valley stand, no. 12-650 (opposite Intel).
Re: Making a variable addressable in GIMPLE
Hi Diego,
Diego Novillo wrote:
> Yoav Etsion wrote:
>
>
>>The problem is that the first mudflap pass takes place at the GIMPLE
>>level, at which point all variables have their
>>addressable/non-addressable attributes set, which forbids me to build an
>>ADDR_EXPR node for a non-addressable pointer variable ("invalid operand
>>to unary & operator" error).
>>
>
> Call build_addr() to create the ADDR_EXPR. It will set the
> TREE_ADDRESSABLE bit on the variable and set some attributes on the
> ADDR_EXPR itself.
>
The code is nicer, but still no go... :)
>
> That message suggest that you may be trying to build the address of a
> non-decl, though. Show me the code and an example of your
transformation?
>
The transformation is simple: mudflap already injects a call to
__mf_register when an addressable variable is declared. I want to do the
same for all pointer variables, so I've added the predicate
POINTER_TYPE_P( TREE_TYPE(decl) )
to the eligibility test (performed on each VAR_DECL node).
gcc is compiled with --enable-checking.
The test code:
>>>
/* avoid including the entire header. */
extern int printf (const char * __format, ...);
int main()
{
int data = 15;
int *data_p = &data;
printf("%d, %d\n", (int)data_p, data);
return 0;
}
<<<
The code dump after the first mudflap pass is:
>>>
{
intD.0 data.0D.781;
intD.0 data_p.1D.782;
intD.0 D.783;
intD.0 dataD.779;
intD.0 * data_pD.780;
try
{
__mf_register (&dataD.779, 4, 3, "simple-stack-pointer.c:6 (main)
data");
__mf_register (&data_pD.780, 4, 3, "simple-stack-pointer.c:7
(main) data_p");
dataD.779 = 15;
data_pD.780 = &dataD.779;
data.0D.781 = dataD.779;
data_p.1D.782 = (intD.0) data_pD.780;
printf (&"%d, %d\n"[0], data_p.1D.782, data.0D.781);
D.783 = 0;
return D.783;
}
finally
{
__mf_unregister (&dataD.779, 4, 3);
__mf_unregister (&data_pD.780, 4, 3);
}
}
<<<
The exact error message is:
>>>
simple-stack-pointer.c: In function 'main':
simple-stack-pointer.c:5: error: Invalid operand to unary operator
data_pD.780
simple-stack-pointer.c:5: internal compiler error: verify_stmts failed.
please submit...
<<<
The error message directs me to the addressability of 'data_p'.
Any ideas?
Thanks,
Yoav Etsion
Re: Reconsidering gcjx
> ecj is written in java. This will complicate the bootstrap process. > However, the situation will not be quite as severe as the Ada > situation, in that it ought to be possible to bootstrap gcj using any > java runtime, including mini ones such as JamVM -- at least, assuming > that the suggested implementation route is taken. I would really hesitate to follow Ada in this regard. IMHO, writing your frontend in the same language it's intended to compile causes it to be marginalized. It no longer becomes part of the default bootstrap sequence and gets much less testing. You'll find patches that were supposedly "bootstrapped and regtested" will quite often break java because it didn't get tested as part of the default. If you want to use a non-C language for java, then C++ is a better choice because you can use G++ in the local tree to compile the java frontend as if the java FE was a target library. No extra dependencies are introduced for bootstrap it just modifies the order things get done. It'll be more complicated for a cross-config, but at least everything you need is in the local src tree. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Reconsidering gcjx
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes: > [...] IMHO, writing your frontend in the same language it's intended > to compile causes it to be marginalized. It no longer becomes part > of the default bootstrap sequence and gets much less testing. [..] Even if so, it may be worth spelling out some of the obvious benefits of writing a compiler in its own language: - genuine bootstrapping capability (to compile itself, being a source of realistic test coverage) - supplies "virtuous circle" motivation for improvement (speed, quality, ...), since it itself directly benefits - providing a concrete, educational systems application of the language (rather than saying "language X would be great for writing compilers, but by the way here is an X compiler written in Y.) - FChE
Re: Making a variable addressable in GIMPLE
Yoav Etsion <[EMAIL PROTECTED]> writes: > The transformation is simple: mudflap already injects a call to > __mf_register when an addressable variable is declared. I want to do > the same for all pointer variables [...] Why? If those pointers are not themselves taken address of, what kind access to the pointer value is worth checking? - FChE
Re: Reconsidering gcjx
[EMAIL PROTECTED] (Frank Ch. Eigler) writes: | - supplies "virtuous circle" motivation for improvement (speed, | quality, ...), since it itself directly benefits Fully agreed. Witness: GNU C :-) -- Gaby
Re: Reconsidering gcjx
On Thu, Jan 26, 2006 at 05:08:20PM -0700, Tom Tromey wrote:
> Now that the GPL v3 looks as though it may be EPL-compatible, the time
> has come to reconsider using the Eclipse java compiler ("ecj") as our
> primary gcj front end. This has both political and technical
> ramifications, I discuss them below.
> Steering committee members, please read through if you would. I think
> this requires some resolution at the SC/FSF level.
The political/legal issues include:
* License compatibility: if we have to wait for GPLv3, we're talking 2007,
even if the FSF is fine with it. Even development before then might
be problematic if developers must link GPL and EPL code.
* Using a language other than C. At least you're talking Java; RMS
so strongly dislikes C++ that he goes nonlinear when the topic is
brought up, though his arguments against it sometimes seem
to reflect the state of C++ 10 years ago.
* The FSF not owning significant parts of the compiler.
But before fighting the political battles, we should first figure out if
this is what we really want to do if there weren't political obstacles.
Let's try coming to a technical consensus first.
Re: Problem with gfortran or did I messsed up GMP installation?
Quoting Eric Botcazou <[EMAIL PROTECTED]>: So, the question is, did I broke something by attempting to have both 32-bit and 64-bit GMP library installed simultaniously? Did I miss anything needed to have both 32-bit and 64-bit GMP available on the system? Do not install both 32-bit and 64-bit GMP, you only need one of them: sparc-sun-solaris2.* compiler -> 32-bit GMP sparc64-sun-solaris2.* compiler -> 64-bit GMP. I did some additional testing. I can reproduce the problem *only* on UltraSPARC-IIe machine. If I run the program on any other machine, it runs correctly. Also, if I statically link program on UltraSPARC-IIe machine, it doesn't run on any other machine. If I statically link it on any other machine, it runs correctly on UltraSPARC-IIe. H... I've filled bug report with more information. This might or might not be the bug in gcc/f951, since obviously there are many more components involved (gmp, mpfr, Solaris system libraries, the processor itself, or any combination). The bug ID is 25998 for those interested. This message was sent using IMP, the Internet Messaging Program.
Re: Problem with gfortran or did I messsed up GMP installation?
> I did some additional testing. I can reproduce the problem *only* on > UltraSPARC-IIe machine. If I run the program on any other machine, it > runs correctly. Weird. > Also, if I statically link program on UltraSPARC-IIe machine, it > doesn't run on any other machine. If I statically link it on any other > machine, it runs correctly on UltraSPARC-IIe. H... > > I've filled bug report with more information. This might or might not > be the bug in gcc/f951, since obviously there are many more components > involved (gmp, mpfr, Solaris system libraries, the processor itself, or > any combination). The bug ID is 25998 for those interested. I'm not sure we'll be able to sort it out but, in any case, thanks for narrowing down the problem and for the extensive testing. -- Eric Botcazou
Re: Making a variable addressable in GIMPLE
The pointer variable's address is used as the pointer's unique ID in a database, collecting information about each pointer variable - mostly its legal bounds. That way I can test when a pointer crosses its object's bounds. Terrible overhead, I know. Just need it to collect statistics about program (or programmer) behavior. Yoav Frank Ch. Eigler wrote: Yoav Etsion <[EMAIL PROTECTED]> writes: The transformation is simple: mudflap already injects a call to __mf_register when an addressable variable is declared. I want to do the same for all pointer variables [...] Why? If those pointers are not themselves taken address of, what kind access to the pointer value is worth checking? - FChE
sh64-elf fails to build with gcc 4.1
The newlib build fails with: /mnt/scratch/nightly/4.1-2006-01-27/sh64-elf/./gcc/xgcc -B/mnt/scratch/nightly/4.1-2006-01-27/sh64-elf/./gcc/ -nostdinc -B/mnt/scratch/nightly/4.1-2006-01-27/sh64-elf/sh64-elf/compact/newlib/ -isystem /mnt/scratch/nightly/4.1-2006-01-27/sh64-elf/sh64-elf/compact/newlib/targ-include -isystem /mnt/scratch/nightly/4.1-2006-01-27/srcw/newlib/libc/include -B/usr/local/sh64-elf/bin/ -B/usr/local/sh64-elf/lib/ -isystem /usr/local/sh64-elf/include -isystem /usr/local/sh64-elf/sys-include -L/mnt/scratch/nightly/4.1-2006-01-27/sh64-elf/./ld -m5-compact -DPACKAGE=\"newlib\" -DVERSION=\"1.14.0\" -I. -I../../../../../../srcw/newlib/libc/stdlib -O2 -DHAVE_GETTIMEOFDAY -fno-builtin -O2 -g -O2 -m5-compact -DINTERNAL_NEWLIB -DDEFINE_REALLOC -c ../../../../../../srcw/newlib/libc/stdlib/mallocr.c -o reallocr.o ../../../../../../srcw/newlib/libc/stdlib/mallocr.c: In function ‘_realloc_r’: ../../../../../../srcw/newlib/libc/stdlib/mallocr.c:2994: internal compiler error: in insert_save, at caller-save.c:719 Please submit a full bug report, with preprocessed source if appropriate. This appears to be the same failure as observed on mainline on November. The patch that fixed this was: 2005-11-24 J"orn Rennecke <[EMAIL PROTECTED]> * caller-save.c: (this_insn_sets): Move into: (save_call_clobbered_regs). (mark_set_regs): Get this_insn_sets from data. (save_call_clobbered_regs): Take sets of the return value by sibcalls into account. http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107469 OK to backport to 4.1 if bootstrap on i686-pc-linux-gnu succeeds?
Re: Reconsidering gcjx
> "Paolo" == Paolo Bonzini <[EMAIL PROTECTED]> writes: Paolo> How big would the mini Java-runtime be? A bytecode-interpreter, with Paolo> only support for two or three packages, using a simple Baker or Paolo> mark'n'sweep GC, could be done in 10,000 lines of C code or maybe less. The problem with a mini JVM in the bootstrap is that it will also need a class library, which has to come from somewhere. Bootstrapping an ecj-based gcj is not as hard as bootstrapping Ada. The class->object compiler will still be C code, so all you will need to bootstrap is the class files for the library. These are platform independent, and can be built with any java compiler on any machine. We could even check in the class files, if need be. Tom
Re: sh64-elf fails to build with gcc 4.1
Joern RENNECKE wrote: > OK to backport to 4.1 if bootstrap on i686-pc-linux-gnu succeeds? Yes. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Corrupted Profile Information
On Jan 26, 2006, at 4:05 PM, [EMAIL PROTECTED] wrote: I really need correct profile information before PRE. By moving rest_of_handle_branch_prob() just before rest_of_handle_gcse() have I violated some critical assumptions which is causing the profile information to be occasionally corrupted ? Yes; various CFG transformations before the profiling phase don't maintain the profiling info, because there isn't any. In gcc-4 the profiling phase has been moved much earlier and this information is maintained by the later transformations. Backporting all that logic to 3.4 might be possible, but is not easy. You're better off using gcc-4.
Re: Reconsidering gcjx
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes: Per> A couple of other factors: Thanks for bringing these up. Per> * Compile time. Yeah, this is a potential problem. If it is severe it could be fixed by linking ecj into GCC. FWIW, at least for all the packaging we do in Fedora, we have to compile things separately, because we're using unmodified upstream build systems. I realize this isn't the only gcj use case. I can try to come up with some timings. Per> * Debugging. Historically Java degugging information is pretty limited. Per>Even with the latest specifications there is (for example) no support Per>for column numbers. However, the classfile format is extensible, and Per>so if needed we can define extra "attribute" sections. Yeah, this could be fixed with some upstream cooperation. Per> * The .classfile format is quite inefficient. For example there is Per>no sharing of "symbols" between classes, so there is a lot of Per>duplication. However, this is a problem we share with everybody Per>else, and it could be solved at the bytecode level, co-operating Per>with other parties, iseally as a Java Specification Request. 1.5 includes Pack200, which addresses this in a somewhat odd way. This seems like a subset of the performance problem though... if performance is ok, this inefficiency won't matter. Per> (2) A bytecode versions of ecj. This is only useful if we also make Per> available a bytecode version of libgcj, I think. Yeah. Right now we have a few java files that we compile based on the target platform, eg the Process stuff. I think we could easily move these around and move to a slightly different approach which would let us have a single libgcj.jar that works for all platforms. For folks not involved in libgcj, the build is essentially done in two steps at the moment. First we compile to class files (this is the classpath part), then we go back and compile to native (using the class files as a kind of precompiled header). In the new setup I think we would compile the class files to object files directly in the second step (since that is what we'd get with ecj anyway). Bringing up libgcj on a new system would involve getting those class files from "somewhere"; with some relatively minor build changes we could just make this a download from gcc.gnu.org. Tom
Re: Reconsidering gcjx
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes: Andrew> In particular, the type system and the rules for exception Andrew> regions are different. Also, a "slot" in the .class format Andrew> doesn't necessarily correspond to a variable in the source Andrew> language. One way to look at this is: we really want to fix these things, because, e.g., we'll probably be compiling all the java code in FC to objects from class files for the foreseeable future anyway (to avoid huge divergences from upstream build setups). Moving to gcjx would turn "writing a 1.5 compiler" from a project taking all of my time for the next year into a project that takes all of my time for 2 months. Then we'd have more time to fix other things. Andrew> In particular, Andrew> .class files don't contain the full pathnames to source files. I think this one we can handle via the specs. Consider a simple compilation like "gcj -g -c foo.java". In my proposal we would turn this into a series of invocations: ecj -g -Xjar /tmp/tmpfile.jar foo.java jc1 blah blah blah -o /tmp/tmpfile2.o tmpfile.jar ... but we could easily have the specs pass the real original file name to jc1. Just as a side note for non-java experts ... the reason we use an intermediate jar file is that a single java compilation may result in multiple .class files. A jar file is convenient because it is simple to make in java, and because gcj already has all the code needed to read and compile one. It occurs to me now that we'll probably need a way to make ecj not compile eagerly. I haven't looked to see whether it already has one. Column numbers, as Per mentioned, are trickier. We know that ecj has this information (since Eclipse itself uses it), but there is no standard way to pass it via the class file format. But does gdb actually use column numbers? Tom
Re: Reconsidering gcjx
On Fri, Jan 27, 2006 at 11:59:06AM -0700, Tom Tromey wrote: > Column numbers, as Per mentioned, are trickier. We know that ecj has > this information (since Eclipse itself uses it), but there is no > standard way to pass it via the class file format. But does gdb > actually use column numbers? Not today, no. -- Daniel Jacobowitz CodeSourcery
Re: Making a variable addressable in GIMPLE
Yoav Etsion <[EMAIL PROTECTED]> writes: > The pointer variable's address is used as the pointer's unique ID in > a database, collecting information about each pointer variable - > mostly its legal bounds. That way I can test when a pointer crosses > its object's bounds. If I understand correctly, you mean to figure out the legally reachable address ranges of individual pointer variables. I don't know what identifying the pointer *declarations* will do for you though. After all, many such declarations may be manufactured for temporary address values. You might instead hook up only to the "mudflap2" pass that tracks actual pointer dereferences. You could analyze the operand of the INDIRECT_REF etc. nodes to figure out which source-level spot caused the dereference. You may be able to follow the links back to a pointer declaration, should one exist. But I may misunderstand the nature of checking you intend. Could you summarize your intended overall algorithm? - FChE
Re: Reconsidering gcjx
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: Joe> But before fighting the political battles, we should first figure out if Joe> this is what we really want to do if there weren't political obstacles. Joe> Let's try coming to a technical consensus first. I made a list of things which would have to be addressed, based mostly on this thread. - Make ecj emit .jar files - Change ecj's error reporting format Right now it is quite ugly and doesn't conform to GNU standards. - Consider putting column numbers in debug info Though as far as I know, nothing uses this today, so I think this is low priority. - Check compile time performance. We don't want to slow gcj down too much. - Make bootstrapping simpler. Some small library refactorings would make it quite simple, amounting to downloading a single jar file. - Exception regions as mentioned by Andrew. I'm not sure what we need to do here. - Fix variable slot tracking for bytecode I don't recall exactly what the problem here was. These last two are already present in today's compiler, though switching to ecj would exacerbate the situation. Tom
Re: Generic vector extensions (execute/simd-2.c)?
On Fri, Jan 27, 2006 at 12:14:40PM +0100, Bernd Schmidt wrote: > Is this something that just isn't supposed to work in 3.4? Probably. I don't remember that code well. > Current > mainline behaves differently and gives me TImode registers (which I'd > rather prefer not to have to deal with either, though, but the compiler > appears able to cope with them so far). If you don't claim to be able to handle TImode at all, via scalar_mode_suppported_p, then it should fall back to BLKmode, and operations on that. r~
Re: Reconsidering gcjx
On Fri, 2006-01-27 at 09:25 -0500, Kaveh R. Ghazi wrote: > > ecj is written in java. This will complicate the bootstrap process. > > However, the situation will not be quite as severe as the Ada > > situation, in that it ought to be possible to bootstrap gcj using any > > java runtime, including mini ones such as JamVM -- at least, assuming > > that the suggested implementation route is taken. > > I would really hesitate to follow Ada in this regard. > > IMHO, writing your frontend in the same language it's intended to > compile causes it to be marginalized. It no longer becomes part of > the default bootstrap sequence and gets much less testing. You'll > find patches that were supposedly "bootstrapped and regtested" will > quite often break java because it didn't get tested as part of the > default. It's a bit annoying but not really blocking: all GCC developpers do fix regressions in Ada when they're properly attributed to a patch, and do follow the project policy that exposing a latent bug elsewhere is not an excuse (and of course if it's traced back to dubious front-end behaviour, front-end maintainer do step in). The consequence is that you have to test separately trunk and your development tree and merge and submit patches only when they both work otherwise you might loose a lot of time to unrelated issues (and that means batch submitting if you do lots of development). Also I believe not allowing new languages for new front-ends might limit the increase of language front-ends in the GNU Compiler Collection: not everyone likes coding parsing and tree algorithms in C in 2006 and I assume a developper wanting to add a new language do like to use this new language :). Wether C++, Java or Ada, a new language requirement looks the same to me: having a good enough base compiler and runtime installed for the language, I do not see anything special to Java or Ada over C++ here. The base compiler I use for building GCC has only c,ada (4.0) because that's what is needed, if c++ is needed I'll add the recommanded c++ compiler, if java and some JVM is needed, I'll add java and the recommanded JVM, no big difference. Currently building trunk with --enable-checking and testing nearly all languages (c,ada,c++,fortran,java,objc,treelang, so excluding Objective C++) on a Pentium III 1GHz machine with 1GB of RAM takes between 11 and 12 hours. It could be more if some languages did have a more substantial testsuite, which is desirable when a front-end matures. Restricting the required number of languages for the default patch testing procedure is unavoidable if we leave it to individual developpers to run on their machine: in 12 hours, about 10 patches are commited to trunk on average. Laurent
Re: Reconsidering gcjx
On Fri, Jan 27, 2006 at 11:09:11PM +0100, Laurent GUERBY wrote: > On Fri, 2006-01-27 at 09:25 -0500, Kaveh R. Ghazi wrote: > > > ecj is written in java. This will complicate the bootstrap process. > > > However, the situation will not be quite as severe as the Ada > > > situation, in that it ought to be possible to bootstrap gcj using any > > > java runtime, including mini ones such as JamVM -- at least, assuming > > > that the suggested implementation route is taken. > > > > I would really hesitate to follow Ada in this regard. > > > > IMHO, writing your frontend in the same language it's intended to > > compile causes it to be marginalized. It no longer becomes part of > > the default bootstrap sequence and gets much less testing. You'll > > find patches that were supposedly "bootstrapped and regtested" will > > quite often break java because it didn't get tested as part of the > > default. Two interesting things I'd like to point out here: - I don't know if it's been a problem lately, but GNAT definitely used to have issues with not just the language it was written in, but what specific version of the compiler was used to bootstrap. ECJ, hopefully, will be less problematic. - People already marginalize gcj because libjava takes so bloody long to build. If ECJ can be noticably faster than GCJ is, this might have the opposite effect. -- Daniel Jacobowitz CodeSourcery
Re: Making a variable addressable in GIMPLE
Frank Ch. Eigler wrote: Yoav Etsion <[EMAIL PROTECTED]> writes: The pointer variable's address is used as the pointer's unique ID in a database, collecting information about each pointer variable - mostly its legal bounds. That way I can test when a pointer crosses its object's bounds. ... But I may misunderstand the nature of checking you intend. Could you summarize your intended overall algorithm? (I'll answer this first, hoping it will also answer the previous two comments) My approach is simple: during dereference we have to check whether the pointer points within its legal boundaries, which should be those of the object assigned to it before any pointer arithmetic. Question is how do we know what the legal boundaries are, as pointer arithmeric might have caused our pointer to jump into an adjacent object? Now, think of the boundaries as attributes that can only change in pointer assignments (not arithmetic). We need to keep a database mapping pointers to boundaries, that is updated with each pointer assignment. So the three operations I need to intercept are pointer dereferences (code which already exists in mudflap2), pointer assignments, and pointer declarations to get the variable's address as the unique database ID (my current predicament). Since I assume automatically generated variables do not induce bugs (hopefully) I don't have to track them (come to think of it, maybe I can do with only assignments and dereferences). Using such database I can both check bounds, and more important to my current research to better understand programming habits and pointer flow. Hope this clears things up, and obviously any comments and suggestions are more than welcome. Yoav - FChE
gcc-4.1-20060127 is now available
Snapshot gcc-4.1-20060127 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060127/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 110312 You'll find: gcc-4.1-20060127.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060127.tar.bz2 C front end and core compiler gcc-ada-4.1-20060127.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060127.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060127.tar.bz2 C++ front end and runtime gcc-java-4.1-20060127.tar.bz2 Java front end and runtime gcc-objc-4.1-20060127.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060127.tar.bz2The GCC testsuite Diffs from 4.1-20060120 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Reconsidering gcjx
On Fri, 2006-01-27 at 17:17 -0500, Daniel Jacobowitz wrote: > Two interesting things I'd like to point out here: > > - I don't know if it's been a problem lately, but GNAT definitely > used to have issues with not just the language it was written > in, but what specific version of the compiler was used to > bootstrap. ECJ, hopefully, will be less problematic. It's indeed likely that Java will benefit from more mature (less likely to have bugs affecting the bootstrap process - most of the GNAT requirements came from here) and established (less likely not to be installed - also a GNAT issue for many platforms) compilers and JVMs when it goes in GCC than Ada at the time, but that does not change the basic requirement for adding a new bootstraped language. If someone comes up with an old JVM that misrun java in GCC and there's no easy obvious workaround, will you cancel the java project or just tell the user to install a known to work JVM from the GCC install documentation? Will the 3.0 gcj and runtime be enough for it to work? Laurent
Mainline is broken on ia64
I got /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c: In function `df_record_entry_block_defs': /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: `INCOMING_RETURN_ADDR_RTX' undeclared (first use in this function) /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: (Each undeclared identifier is reported only once /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: for each function it appears in.) make[5]: *** [df-scan.o] Error 1 make[5]: *** Waiting for unfinished jobs [EMAIL PROTECTED] gcc]$ grep INCOMING_RETURN_ADDR_RTX *.c df-scan.c: if (REG_P (INCOMING_RETURN_ADDR_RTX)) df-scan.c: bitmap_set_bit (df->entry_block_defs, REGNO (INCOMING_RETURN_ADDR_RTX)); dwarf2out.c: INCOMING_RETURN_ADDR_RTX. */ dwarf2out.c: initial_return_save (INCOMING_RETURN_ADDR_RTX); function.c:#if defined(HAVE_epilogue) && defined(INCOMING_RETURN_ADDR_RTX) function.c:#if defined(HAVE_epilogue) && defined(INCOMING_RETURN_ADDR_RTX) function.c: rtx retaddr = INCOMING_RETURN_ADDR_RTX; function.c:#ifdef INCOMING_RETURN_ADDR_RTX df-scan.c doesn't check if INCOMING_RETURN_ADDR_RTX is defined. H.J.
Re: Reconsidering gcjx
> "Laurent" == Laurent GUERBY <[EMAIL PROTECTED]> writes: Laurent> If someone comes up with an old JVM that misrun java in GCC Laurent> and there's no easy obvious workaround, will you cancel the Laurent> java project or just tell the user to install a known to work Laurent> JVM from the GCC install documentation? Will the 3.0 gcj and Laurent> runtime be enough for it to work? I assume these questions come from previous Ada bootstrap issues. Please, let's not get overly involved in comparing this plan to Ada. I know it is similar, but it is also different in some important ways. The fix for the problem you outline is not very hard. All you need are the .class files corresponding to the .java files in your source tree. These can be made on any machine with any java bytecode compiler that works. Currently this would include the already existing gcj... but seeing as one of the major features of this proposed change is fixing a ton of front end bugs, I would guess that eventually this will no longer work. But even in this case you can run ecj today on gij. And, you can download ecj jars from eclipse.org. This is pretty much like ordinary compiler bootstrapping, except you don't need a cross toolchain, since the needed intermediate results are machine-independent. Tom
Re: Mainline is broken on ia64
H. J. Lu wrote: > I got > > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c: In function > `df_record_entry_block_defs': > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: > `INCOMING_RETURN_ADDR_RTX' undeclared (first use in this function) > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: (Each > undeclared identifier is reported only once > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: for each > function it appears in.) > make[5]: *** [df-scan.o] Error 1 > make[5]: *** Waiting for unfinished jobs > > [EMAIL PROTECTED] gcc]$ grep INCOMING_RETURN_ADDR_RTX *.c > df-scan.c: if (REG_P (INCOMING_RETURN_ADDR_RTX)) > df-scan.c: bitmap_set_bit (df->entry_block_defs, REGNO > (INCOMING_RETURN_ADDR_RTX)); > dwarf2out.c: INCOMING_RETURN_ADDR_RTX. */ > dwarf2out.c: initial_return_save (INCOMING_RETURN_ADDR_RTX); > function.c:#if defined(HAVE_epilogue) && > defined(INCOMING_RETURN_ADDR_RTX) > function.c:#if defined(HAVE_epilogue) && > defined(INCOMING_RETURN_ADDR_RTX) > function.c: rtx retaddr = INCOMING_RETURN_ADDR_RTX; > function.c:#ifdef INCOMING_RETURN_ADDR_RTX > > df-scan.c doesn't check if INCOMING_RETURN_ADDR_RTX is defined. Actually, neither does dwarf2out.c specifically check for it, it assumes it's defined if DWARF2_UNWIND_INFO does. #ifdef DWARF2_UNWIND_INFO /* On entry, the Canonical Frame Address is at SP. */ dwarf2out_def_cfa (NULL, STACK_POINTER_REGNUM, INCOMING_FRAME_SP_OFFSET); initial_return_save (INCOMING_RETURN_ADDR_RTX); #endif Can you try the obvious patch here (surrounding INCOMING_RETURN_ADDR_RTX with an ifdef)?
RE: Reconsidering gcjx
> From: Laurent GUERBY > Wether C++, Java or Ada, a new language requirement looks the same to > me: having a good enough base compiler and runtime installed > for the language, I do not see anything special to Java or > Ada over C++ here. The base compiler I use for building GCC > has only c,ada (4.0) because that's what is needed, if c++ is > needed I'll add the recommanded c++ compiler, if java and > some JVM is needed, I'll add java and the recommanded JVM, no > big difference. As others have pointed out, there's potentially a small difference in the case of Java, in that I believe the .class -> .o part of the compiler would still be buildable without an existing JVM, and perhaps even somewhat tested without one. And that's the part that's likely to break if other parts of the compiler are changed. I don't think Ada has an analog to that. Hans
RE: Reconsidering gcjx
As others have pointed out, there's potentially a small difference in the case of Java, in that I believe the .class -> .o part of the compiler would still be buildable without an existing JVM, and perhaps even somewhat tested without one. And that's the part that's likely to break if other parts of the compiler are changed. I don't think Ada has an analog to that. This is a historical aside, but interestingly enough Ada (GNAT) *did* have such a thing in the *very* early days, but it was decided that the trouble involved in maintaining and using the mechanism was much larger than other available bootstrap methods. The difference between this and Java is that the mechanism in question has other uses for Java, but none for Ada.
Re: Reconsidering gcjx
Tom Tromey wrote:
> Now that the GPL v3 looks as though it may be EPL-compatible, the time
> has come to reconsider using the Eclipse java compiler ("ecj") as our
> primary gcj front end. This has both political and technical
> ramifications, I discuss them below.
First, I'd like to commend and thank you just for brining this issue up.
It takes a lot of courage to look at your own hard work and consider
tossing it out.
My personal feeling is that using ecj would be an excellent approach.
I'm not qualified to talk about all the particular technical issues, but
I think that focusing free software developers on a single Java front
end is an excellent idea, and since you believe ecj is an actively
maintained high-quality complier, that seems fine.
As others have said, the bootstrapping issues are much more minor than
GNAT, since there are free java runtimes that can run ecj; the severity
of the "you must have version X of to build version Y" is rather
less.
The FSF's web site lists the EPL as a GPL-incompatible free software
license, but I don't think that's an issue. We could argue about
whether or not invoking ecj from the driver, before feeding the class
file to gcj, somehow constitutes a combination under GPLv2, but I think
that's relatively pointless. I think the general consensus is that
nobody knows for sure (lack of case law), but that most people assume
the GPL applies to programs linked together, and we certainly don't
assume a GPL problem because GCC on Solaris invokes the Solaris assembler!
Of course, we should definitely get the SC's buy in before making such a
change of this magnitude.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: Reconsidering gcjx
> Also I believe not allowing new languages for new front-ends might > limit the increase of language front-ends in the GNU Compiler > Collection: I think "not allowing" is too strong a characterization of my previous message. I have neither the inclination or the power to do that on my own. I do however feel extra caution is in order... > Wether C++, Java or Ada, a new language requirement looks the same to > me: having a good enough base compiler and runtime installed for the > language, I do not see anything special to Java or Ada over C++ here. The issue for me is not C++ vs Java vs Ada. The issue is writing the language frontend in the same language it parses so that it depends on itself to bootstrap. If we wrote the G++ FE in java and the java FE in C that would satisfy my concern just as well as the reverse of writing java FE in C++ and the G++ FE in C. Either way we can get from start to finish with only a C compiler to start with. However with Tom's proposal, we need an existing java compiler for our target. This same requirement for Ada has caused lots of confusion. (Which prior versions of Ada work? Does our configure infrastructure handle everything correctly?) Looking at the testsuite results, many of the people who don't bother to compile Ada do currently compile and test java. I suspect if we make it harder to boot/test java then we'll see it's testing and support decline. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Reconsidering gcjx
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes: [...] | However with Tom's proposal, we need an existing java compiler for our | target. I don't believe the issues at hand here (Java specific case) are as severe as they sound from your messages. If GCC creators had to follow the reasoning developed in your messages, your should have had gcc to start with. In 2006, I believe the availability of java front-ends for bootsstrapping the GNU Java is sufficiently widespread enough to outweight and overcome the potential problems you're anticipating. We desperatly need to get GCC more supported, more integrated into widely used development tools. We cannot sustain improvements, competition by isolating and painting ourselves into corners. -- Gaby
Re: Reconsidering gcjx
Another concern: I gather there are lots of dependencies between Eclipse libraries. Does ecj depend on any other Eclipse libraries? Even if there are no run-time dependencies, it's awkward if a class statically references some random Eclipse class that somehow pulls in large parts of Eclipse. I.e. I'm hoping one can *statically* link ecj without any dependencies on (say) the SWT toolkit, or the debugger? This is not an absolute requirement, and if there are just a couple of troublesome dependencies, it is normally possible (if ugly) to turn a static dependency into a run-time check, using reflection. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Reconsidering gcjx
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes: Per> Another concern: I gather there are lots of dependencies Per> between Eclipse libraries. Does ecj depend on any other Per> Eclipse libraries? Good point. I forgot to mention this. The Eclipse compiler is standalone by design. The project to look at is 'org.eclipse.jdt.core'. You can get it from :pserver:[EMAIL PROTECTED]:/cvsroot/eclipse There are a lot of directories in this module; the compiler core itself is in 'compiler' and 'batch'. The only dependency these files have is J2SE. (The code outside these directories does depend on the rest of Eclipse, but we would not build that.) In fact we exploit this to build the system 'javac' for Fedora Core. We also are currently building the Eclipse compiler nightly on the Classpath build machine. One minor risk for this project is that the upstream compiler will change this for some reason. However, I don't think that is a very major risk; they've actually been quite interested in what we've done for FC. Also, due to the builder, we'll know the same day that anything breaks :-) Tom
Re: Mainline is broken on ia64
On Fri, Jan 27, 2006 at 06:20:41PM -0500, Daniel Berlin wrote:
> H. J. Lu wrote:
> > I got
> >
> > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c: In function
> > `df_record_entry_block_defs':
> > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error:
> > `INCOMING_RETURN_ADDR_RTX' undeclared (first use in this function)
> > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: (Each
> > undeclared identifier is reported only once
> > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: for each
> > function it appears in.)
> > make[5]: *** [df-scan.o] Error 1
> > make[5]: *** Waiting for unfinished jobs
> >
> > [EMAIL PROTECTED] gcc]$ grep INCOMING_RETURN_ADDR_RTX *.c
> > df-scan.c: if (REG_P (INCOMING_RETURN_ADDR_RTX))
> > df-scan.c: bitmap_set_bit (df->entry_block_defs, REGNO
> > (INCOMING_RETURN_ADDR_RTX));
> > dwarf2out.c: INCOMING_RETURN_ADDR_RTX. */
> > dwarf2out.c: initial_return_save (INCOMING_RETURN_ADDR_RTX);
> > function.c:#if defined(HAVE_epilogue) &&
> > defined(INCOMING_RETURN_ADDR_RTX)
> > function.c:#if defined(HAVE_epilogue) &&
> > defined(INCOMING_RETURN_ADDR_RTX)
> > function.c: rtx retaddr = INCOMING_RETURN_ADDR_RTX;
> > function.c:#ifdef INCOMING_RETURN_ADDR_RTX
> >
> > df-scan.c doesn't check if INCOMING_RETURN_ADDR_RTX is defined.
>
> Actually, neither does dwarf2out.c specifically check for it, it assumes
> it's defined if DWARF2_UNWIND_INFO does.
>
> #ifdef DWARF2_UNWIND_INFO
> /* On entry, the Canonical Frame Address is at SP. */
> dwarf2out_def_cfa (NULL, STACK_POINTER_REGNUM, INCOMING_FRAME_SP_OFFSET);
> initial_return_save (INCOMING_RETURN_ADDR_RTX);
> #endif
>
>
> Can you try the obvious patch here (surrounding INCOMING_RETURN_ADDR_RTX
> with an ifdef)?
>
This patch works for me.
H.J.
---
2006-01-27 H.J. Lu <[EMAIL PROTECTED]>
* df-scan.c (df_record_entry_block_defs): Check if
INCOMING_RETURN_ADDR_RTX is defined.
--- gcc/df-scan.c.foo 2006-01-27 14:24:43.0 -0800
+++ gcc/df-scan.c 2006-01-27 15:28:31.0 -0800
@@ -1750,8 +1750,10 @@ df_record_entry_block_defs (struct dataf
}
else
{
+#ifdef INCOMING_RETURN_ADDR_RTX
if (REG_P (INCOMING_RETURN_ADDR_RTX))
bitmap_set_bit (df->entry_block_defs, REGNO (INCOMING_RETURN_ADDR_RTX));
+#endif
/* If STATIC_CHAIN_INCOMING_REGNUM == STATIC_CHAIN_REGNUM
only STATIC_CHAIN_REGNUM is defined. If they are different,
Re: Mainline is broken on ia64
H. J. Lu wrote: > On Fri, Jan 27, 2006 at 06:20:41PM -0500, Daniel Berlin wrote: >> H. J. Lu wrote: >>> I got >>> >>> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c: In function >>> `df_record_entry_block_defs': >>> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: >>> `INCOMING_RETURN_ADDR_RTX' undeclared (first use in this function) >>> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: (Each >>> undeclared identifier is reported only once >>> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error: for each >>> function it appears in.) >>> make[5]: *** [df-scan.o] Error 1 >>> make[5]: *** Waiting for unfinished jobs >>> >>> [EMAIL PROTECTED] gcc]$ grep INCOMING_RETURN_ADDR_RTX *.c >>> df-scan.c: if (REG_P (INCOMING_RETURN_ADDR_RTX)) >>> df-scan.c: bitmap_set_bit (df->entry_block_defs, REGNO >>> (INCOMING_RETURN_ADDR_RTX)); >>> dwarf2out.c: INCOMING_RETURN_ADDR_RTX. */ >>> dwarf2out.c: initial_return_save (INCOMING_RETURN_ADDR_RTX); >>> function.c:#if defined(HAVE_epilogue) && >>> defined(INCOMING_RETURN_ADDR_RTX) >>> function.c:#if defined(HAVE_epilogue) && >>> defined(INCOMING_RETURN_ADDR_RTX) >>> function.c: rtx retaddr = INCOMING_RETURN_ADDR_RTX; >>> function.c:#ifdef INCOMING_RETURN_ADDR_RTX >>> >>> df-scan.c doesn't check if INCOMING_RETURN_ADDR_RTX is defined. >> Actually, neither does dwarf2out.c specifically check for it, it assumes >> it's defined if DWARF2_UNWIND_INFO does. >> >> #ifdef DWARF2_UNWIND_INFO >> /* On entry, the Canonical Frame Address is at SP. */ >> dwarf2out_def_cfa (NULL, STACK_POINTER_REGNUM, INCOMING_FRAME_SP_OFFSET); >> initial_return_save (INCOMING_RETURN_ADDR_RTX); >> #endif >> >> >> Can you try the obvious patch here (surrounding INCOMING_RETURN_ADDR_RTX >> with an ifdef)? >> > > This patch works for me. > > IMHO, you should commit it as obvious then.
reg-stack.c potpourri
1) What would need to be done to reg-stack.c to allow other ports besides i386 to use it? (support for multiple-stack machines would be REALLY nice, but rather far off) (any other ideas?) 2) I found a minor bug in the header comment for reg-stack.c -- when whoever wrote the comment documented "push" insns, they said SET_DEST was two things at the same time and never said what SET_SRC was! Is the SET_DEST supposed to be FIRST_STACK_REG, or a plain REG or MEM?
Re: Reconsidering gcjx
> "Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes: > > | However with Tom's proposal, we need an existing java compiler for > | our target. > > I don't believe the issues at hand here (Java specific case) are as > severe as they sound from your messages. Okay fine, let's quantify it. I downloaded the Dec 2005 gcc-testresults archive from: ftp://gcc.gnu.org/pub/gcc/mail-archives/gcc-testresults/gcc-testresults-2005-12.bz2 Then i ran this shell pipeline: grep '\--enable-languages=' gcc-testresults-2005-12 | sed 's/.*--enable-languages=//; s/ .*$//' | tr ',' '\n' | sort | uniq -c | sort -nr and I got: 1690 c 1659 c++ 1379 objc 1233 java 945 fortran 451 ada 292 treelang 229 obj-c++ 228 f95 185 f77 14 pascal 13 for 3 2 3Dc 1 treela= 1 c+ 1 ;t 1 3Dfortran (Note: fortran + f95 + f77 = 1358 or about on par with Java.) As you can see, Java currently gets less testing than c/c++ but its still about 3x the testing that Ada gets. Part of the reason for Ada's low numbers is the extra prerequisite placed on bootstrapping. I'd like to avoid having Java fall lower than it already is. > In 2006, I believe the availability of java front-ends for > bootsstrapping the GNU Java is sufficiently widespread enough to > outweight and overcome the potential problems you're anticipating. I don't think it matters how available it is. Many testers and developers just won't bother. > We desperatly need to get GCC more supported, more integrated into > widely used development tools. We cannot sustain improvements, > competition by isolating and painting ourselves into corners. > -- Gaby I think we agree on that goal and I've said my piece. If others think the benefits of using Java in the Java FE are worthwhile I won't oppose it. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Reconsidering gcjx
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes: | > "Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes: | > | > | However with Tom's proposal, we need an existing java compiler for | > | our target. | > | > I don't believe the issues at hand here (Java specific case) are as | > severe as they sound from your messages. | | Okay fine, let's quantify it. I downloaded the Dec 2005 | gcc-testresults archive from: | ftp://gcc.gnu.org/pub/gcc/mail-archives/gcc-testresults/gcc-testresults-2005-12.bz2 | | Then i ran this shell pipeline: | | grep '\--enable-languages=' gcc-testresults-2005-12 | sed 's/.*--enable-languages=//; s/ .*$//' | tr ',' '\n' | sort | uniq -c | sort -nr | | and I got: | |1690 c |1659 c++ |1379 objc |1233 java | 945 fortran | 451 ada | 292 treelang | 229 obj-c++ | 228 f95 | 185 f77 | 14 pascal | 13 for | 3 | 2 3Dc | 1 treela= | 1 c+ | 1 ;t | 1 3Dfortran | | (Note: fortran + f95 + f77 = 1358 or about on par with Java.) Thanks for the data. | As you can see, Java currently gets less testing than c/c++ but its | still about 3x the testing that Ada gets. Part of the reason for | Ada's low numbers is the extra prerequisite placed on bootstrapping. | I'd like to avoid having Java fall lower than it already is. I understand your goal. However, I do not believe that the reasons you give to explain the Ada situation carry verbatim to the Java situation. From the description I've seen and following the regular Ada bootstrapping issues, it strikes that the situations are quite dissimilar, even though they bear some ressemblance points. Tom has provided a data point that theu used the Eclipse compiler to build javac. It is not like we only have one source of widely used java compiler. And we may even not need to full blown one. | > In 2006, I believe the availability of java front-ends for | > bootsstrapping the GNU Java is sufficiently widespread enough to | > outweight and overcome the potential problems you're anticipating. | | I don't think it matters how available it is. that has been one of the fundamental issue with the Ada front-end, with requirements on specific version. | Many testers and developers just won't bother. See, my conclusion then is it must not be the language in which it is written issue. Having the compiler written in C does not automatically drag hundreds of testers or developers batalions. But it does have the disavantage of not stressing the front-end as one written in Java would. Letting the Java front-end more integrated to the Java community tools have the potential of dragging more interested people (its community and developers) than the already scare C-only GCC developers. | > We desperatly need to get GCC more supported, more integrated into | > widely used development tools. We cannot sustain improvements, | > competition by isolating and painting ourselves into corners. | > -- Gaby | | I think we agree on that goal and I've said my piece. If others think | the benefits of using Java in the Java FE are worthwhile I won't | oppose it. FWIW, given the scarce resource we -- and especially the Java folks -- have, we should not put the bar higher than necessary. The idea outlined by Tom sounds sensible to me and worths exploring. He provided data points that indicate that the idea is not totally alien to working. -- Gaby
