gcc-4.2-20060128 is now available
Snapshot gcc-4.2-20060128 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060128/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 110328 You'll find: gcc-4.2-20060128.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20060128.tar.bz2 C front end and core compiler gcc-ada-4.2-20060128.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20060128.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20060128.tar.bz2 C++ front end and runtime gcc-java-4.2-20060128.tar.bz2 Java front end and runtime gcc-objc-4.2-20060128.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20060128.tar.bz2The GCC testsuite Diffs from 4.2-20060121 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
Registers that must be preserved inside a function
Hi list! I was playing with some disassembly these days and I noticed that some functions stores global vars in ebx register and then it may call another functions assuming that ebx will be unchanged when the control back to the caller! I have a post with more details about this assembly code at: http://gotfault.net/paste/index.php?show=4 Well, i read that some register must be preserved in function, but dont know if that is true and what register must be unchanged in a function anyone can explain me this?? regards Carlos Barros
debug_hooks->end_prologue problem
The HP debugger on IA64 VMS defines a new Dwarf2 attribute that computes the
offset of the end of the prologue from the beginning of the function. To
implement this an end prologue label must be emitted and some related info
saved in dwarf2out.c.
However I've noted that calling debug_hooks->end_prologue as it is now
results in a label at the beginning of the prologue, not the end. I've
attached the obvious fix below, but I fear it might mess up sdbout.c. Should
I create a new hook or investigate the impact on sdbout and try to fix it?
--Douglas Rupp
AdaCore
*** gcc/final.c 2006-01-26 00:39:12.0 -0800
--- gcc/final.c 2006-01-26 00:12:21.0 -0800
*** final_scan_insn (rtx insn, FILE *file, i
*** 1704,1709
--- 1704,1710
case NOTE_INSN_PROLOGUE_END:
(*targetm.asm_out.function_end_prologue) (file);
profile_after_prologue (file);
+ (*debug_hooks->end_prologue) (last_linenum, last_filename);
if ((*seen & (SEEN_EMITTED | SEEN_NOTE)) == SEEN_NOTE)
{
*** final_scan_insn (rtx insn, FILE *file, i
*** 1716,1727
break;
case NOTE_INSN_EPILOGUE_BEG:
(*targetm.asm_out.function_begin_epilogue) (file);
break;
case NOTE_INSN_FUNCTION_BEG:
app_disable ();
- (*debug_hooks->end_prologue) (last_linenum, last_filename);
if ((*seen & (SEEN_EMITTED | SEEN_NOTE)) == SEEN_NOTE)
{
Re: Reconsidering gcjx
On Fri, 2006-01-27 at 16:41 -0800, Per Bothner wrote: > I.e. I'm hoping one can *statically* link ecj without any > dependencies on (say) the SWT toolkit, or the debugger? Yes, you can. And when references have crept in by mistake, the Eclipse guys were pretty quick about removing them. BTW, the compiler can be checked out and built from this module... cvs -z3 -d:pserver:[EMAIL PROTECTED]:/home/eclipse co org.eclipse.jdt.core (For the record, I think if people ask the Eclipse compiler people about "ecj" they'll have no idea what you're talking about! It was just invented when we first started building it as a stand-alone batch compiler in order to build Eclipse via RPM. It was a convenient name to use since upstream didn't provide one.) AG
Re: Reconsidering gcjx
Tom Tromey <[EMAIL PROTECTED]> writes: > 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. I (and David Crawshaw) have actually done this. http://tool.ibex.org/ The Eclipse compiler is great. I really like it. Plus, lots of tools are designed to use Java bytecode as an intermediate format (however ill-suited it may be for that task). Making bytecode the primary input format for gcj would make coupling such tools to gcj a less out-there-in-left-field sort of thing. - a
Re: reg-stack.c potpourri
"Lucas \(a.k.a T-Bird or bsdfan3\)" <[EMAIL PROTECTED]> writes: > 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?) reg-stack.c is pretty closed tied to the x87 FP instructions used on IA32. It has specific knowledge of which instructions use which slots on the stack, e.g., in subst_stack_regs_pat. More seriously, I don't think the general approach of treating every stack slot as a hard register and then turning that into stack manipulation is going to give you optimal code. If you are compiling for a stack machine, I would think that you should select instructions and allocate registers with the stack architecture in mind. But if you are committed to using gcc, then using something along the lines of reg-stack.c may be your best bet. > 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? It should read: A "push" or "load" insn is a SET whose SET_DEST is FIRST_STACK_REG and whose SET_SRC is REG or MEM. Ian
Re: Reconsidering gcjx
Sorry to reply late to this thread. First I think concentrating on a native bytcode compiler for java makes excellent sense it decouples you from the front end implementation. And I agree that the eclipse compiler is a good choice. I'd have to add that jikes is also resonable. I would like to say that my intrest in gcjx is not so much a java compiler but as a framework for developing native compilers for objects oriented languages like ruby python etc etc. Thus I think in a bigger context were gcjx became more of a compiler suite for languages that generally are only implemented as interpeted is important. So I think there is a lot of value in gcjx from this view point and a compiler target for bytecode is not the solution for this class of problems. Also C++ probably makes more sense for a generic frontend then java does. Now it may be possible to extend the bytecode to handle efficient compliation of languages such as ruby and thats pretty intresting but generally bytecode makes implicit restrictions on the language MS CLR is not truely generic for example but certianly it more complete then java bytecode. I really don't see bytecode->native compilers ever being really generic.
