Re: core changes for mep port
>>> Look at the calls to cgraph_mark_edge in ipa-inline.c >> There is no such function. I couldn't find anything in ipa-inline >> that (1) had access to both ends of the call edge, (2) was actually >> called, and (3) was called before the inlining happened. > > Sorry, I meant cgraph_mark_inline. It looks like what you want to > me. But maybe I'm misreading it. And cgraph_check_inline_limits (could rename it to cgraph_should_inline_p or something like that, or just call the target hook wherever that function is called now; the target hook should also have a parameter for the reason why inlining is forbidden). Paolo
Re: core changes for mep port
Guys - what branch/tag are you looking at doing this on? I've been in discussions with Dorit about SPMD utilisation of graphics cards (AMD CTM) which has more inline with parallel asymetric architectures than it does with simple SIMD optimisations. Cheers, Nick. > ---Original Message--- > From: DJ Delorie <[EMAIL PROTECTED]> > Subject: Re: core changes for mep port > Sent: 16 Mar '07 03:09 > > > > Do you mean where is the best place to call these functions? > > Yup. > > > Look at the calls to cgraph_mark_edge in ipa-inline.c > > There is no such function. I couldn't find anything in ipa-inline > that (1) had access to both ends of the call edge, (2) was actually > called, and (3) was called before the inlining happened. > > > and look at inline_forbidden_p--there I assume that cfun will hold > > the caller. > > cfun holds the callee. I found a lot of functions that only had > access to the callee (no help there). I also found lots of functions > that looked promising but were never called. >
Re: Constrain not satisfied - floating point insns.
Jim Wilson <[EMAIL PROTECTED]> writes: > Dave Korn wrote: >> But it is ok to use a define_expand (that accepts all alternatives) for >> movsf and use that to generate one of several movsf_ insns, isn't it? > > Reload doesn't use the move define_expands. It can't. A define_expand > is allowed to do stuff like generate new RTL that would completely mess > up what reload is trying to do. That isn't unconditionally true, is it? reload1.c:gen_reload uses gen_move_insn, which is just a start_sequence/end_sequence wrapper for emit_move_insn_1, which in turn calls the move expanders. Richard
RE: Constrain not satisfied - floating point insns.
On 16 March 2007 15:30, Richard Sandiford wrote: > Jim Wilson <[EMAIL PROTECTED]> writes: >> Dave Korn wrote: >>> But it is ok to use a define_expand (that accepts all alternatives) for >>> movsf and use that to generate one of several movsf_ insns, isn't it? >> >> Reload doesn't use the move define_expands. It can't. A define_expand >> is allowed to do stuff like generate new RTL that would completely mess >> up what reload is trying to do. > > That isn't unconditionally true, is it? reload1.c:gen_reload > uses gen_move_insn, which is just a start_sequence/end_sequence > wrapper for emit_move_insn_1, which in turn calls the move expanders. Yes, in fact isn't this the reason why you have to take great care in movMM expanders to check for no_new_pseudos? It may or may not be technically correct, but it's certainly the standard practice for movDI - almost every backend uses an expander instead of an insn. cheers, DaveK -- Can't think of a witty .sigline today
Re: core changes for mep port
> Guys - what branch/tag are you looking at doing this on? It's only a couple of lines of code, do we need a branch for that? Or do you mean the COPmode changes, which are bigger? They still might be managable enough for trunk, if the timing is right.
The Linux binutils 2.17.50.0.13 is released
This is the beta release of binutils 2.17.50.0.13 for Linux, which is
based on binutils 2007 0315 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.17.50.0.13 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.17.50.0.12:
1. Update from binutils 2007 0315.
2. Add EFI/x86-64 support.
3. Fix ELF linker for relocation against STN_UNDEF. PR 3958.
4. Fix ELF linker for SHT_NOBITS section whose VMA > page size. PR 4144.
5. Make assembler and disassembler consistent for "test %eax,%ebx". PR
4027.
6. Fix i386 32bit address wraparound. PR 3966.
7. Allow Linux/i386 linker to read FreeBSD/i386 object files.
8. Fix ELF linker crash upon use of .gnu.warning. sections. PR
3953.
9. Fix ELF linker to issue an error on bad section in segment. PR 4007.
10. Support enabling both x86_64-mingw32 and i386-mingw32. PR 3945.
11. Fix assembler to stabilize .gcc_except_table relaxation. PR 4029.
12. Fix a MIPS linker crash. PR 3852.
13. Fix readelf for h8300-elf. PR 3800.
14. Fix strip for Solaris. PR 3535.
15. Misc xtensa bug fixes.
16. Misc PPC bug fixes.
17. Misc SPU bug fixes.
18. Add support for Toshiba MeP.
Changes from binutils 2.17.50.0.11:
1. Update from binutils 2007 0128.
2. Remove duplicate code in x86 assembler.
3. Fix 32bit and 64bit HPPA/ELF.
Changes from binutils 2.17.50.0.10:
1. Update from binutils 2007 0125.
2. Support environment variables, LD_SYMBOLIC for -Bsymbolic and
LD_SYMBOLIC_FUNCTIONS for -Bsymbolic-functions.
3. Build binutils rpm with LD_SYMBOLIC_FUNCTIONS=1 and reduce PLT
relocations in libfd.so by 84%.
4. Enable sharable sections only for ia32, x86-64 and ia64.
5. Properly handle PT_GNU_RELRO segment for objcopy.
Changes from binutils 2.17.50.0.9:
1. Update from binutils 2007 0122.
2. Implement sharable section proposal for ia32, x86-64 and ia64:
http://groups-beta.google.com/group/generic-abi
3. Implement linker enhancement, -Bsymbolic-functions,
--dynamic-list-cpp-new and --dynamic-list-data. PR 3831.
4. Implement new linker switch, --default-script=FILE/-dT FILE.
5. Check EI_OSABI when reading ELF files. PR 3826.
6. Fix x86 assembler error message. PR 3830.
7. Fix a bug in ld testsuite. PR 1283.
8. Don't include archive64.o for 32bit target. PR 3631.
9. Support -z max-page-size and -z common-page-size in user provided
linker script.
10. Fix 32bit library support for GNU/kFreeBSD/x86-64. PR 3843.
11. Fix some bugs in Score assembler. PR 3871.
12. Fix various bugs in ARM assembler. PR 3707 and more.
13. Add Fido support.
Changes from binutils 2.17.50.0
Re: GCC 4.2 branch comparision failure building Java
On Tue, 13 Mar 2007, Mark Mitchell wrote: > The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: > > Comparing stages 2 and 3 > Bootstrap comparison failure! > ./java/parse.o differs > ./java/parse-scan.o differs This is caused by --enable-generated-files-in-srcdir, as used by the release script, hence not being seen by people configuring normally without that option. The first time Java is built (stage 2), the file java/parse.c is generated in the build directory and compiled from the build directory; only some time after parse.o is built does parse.c get copied to the source directory. The second time (stage 3) it's built from the source directory because of the VPATH setting. Building from different paths means different debug info. This didn't apply with 4.1 because then, without toplevel bootstrap, all files to be copied to the source directory were generated and copied in stage 1, so stage 2 and stage 3 both built them from the source directory. Now, stage 1 is not only built as C only but the whole stage 1 build directory is configured as C only, and so Java generated files don't get copied until stage 2. I have no suggested solution, other than ceasing to include files generated with bison, flex and makeinfo in releases for 4.2 and later. (The GNU Coding Standards describe such generated files with "We commonly include" rather than with a requirement to include them.) I've found another issue that can cause comparison failures in some circumstances; I'll file a PR for that. -- Joseph S. Myers [EMAIL PROTECTED]
Re: error: unable to find a register to spill in class 'FP_REGS'
Again with attachment and CC to the Mailing List. Sorry for missing this.
Regards,
Markus
---
Hello,
thanks for your instructions. Indeed you were right. I mixed up some files.
Again an excerpt of the output-files:
---snip--- // expand
(insn 45 47 46 1 (set (subreg:SI (reg:DI 92 [ D.1212 ]) 4)
(reg:SI 93 [ D.1211 ])) -1 (nil)
(expr_list:REG_NO_CONFLICT (reg:SI 93 [ D.1211 ])
(nil)))
---snap---
---snip--- // lreg
(insn 45 47 46 0 (set (subreg:SI (reg:DI 92 [ D.1212 ]) 4)
(reg:SI 93 [ D.1211 ])) 40 {movsi_general} (nil)
(expr_list:REG_DEAD (reg:SI 93 [ D.1211 ])
(expr_list:REG_NO_CONFLICT (reg:SI 93 [ D.1211 ])
(nil
---snap---
---snip--- // greg
;; Function main (main)
Spilling for insn 45.
---snap---
Aditionally, you can find the three files in the attachment. It would be
really nice of you if you could have a look at it. Maybe you can get a
clue what's going wrong.
Regards,
Markus Franke
Jim Wilson wrote:
> Markus Franke wrote:
>
>> That means the compiler has to reload the pseudo registers 92 and 93 for
>> this instruction, right?
>
>
> First we do register allocation. Then, after register allocation, if
> the chosen hard registers don't match the constraints, then we use
> reload to fix it.
>
>> The relevant data for instruction 45 in .greg looks like that:
>
>
> Insn 45 in the greg dump looks nothing like the insn 45 in the expand
> dump, which means you are looking at the wrong insn here. But it was
> insn 45 in the original mail. Did you change the testcase perhaps? Or
> use different optimization options?
>
> The info we are looking for should look something like this
> Reloads for insn # 13
> Reload 0: reload_out (SI) = (reg:SI 97)
> R1_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
> reload_out_reg: (reg:SI 97)
> reload_reg_rtx: (reg:SI 1 %r1)
>
>> ;; Register 92 in 9.
>> ;; Register 93 in 10.
>
>
> This tells us that pseudo 92 was allocated to hard reg 9, and pseudo 93
> was allocated to hard reg 10. I didn't see reg class preferencing info
> for these regs, but maybe it is in one of the other dump files.
>
> The earlier message has rtl claiming that pseudo 92 got allocated to
> register 1 (r1). I seem to be getting inconsistent information here.
--
Nichts ist so praktisch wie eine gute Theorie!
;; Function main (main)
;; Generating RTL for tree basic block 0
;;
;; Full RTL generated for this function:
;;
(note 2 0 6 NOTE_INSN_DELETED)
;; Start of basic block 0, registers live: (nil)
(note 6 2 3 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(note 3 6 180 0 NOTE_INSN_FUNCTION_BEG)
(insn 180 3 4 0 (set (reg:SI 139)
(reg/f:SI 29 r29)) -1 (nil)
(nil))
(note 4 180 5 0 NOTE_INSN_DELETED)
(call_insn 5 4 7 0 (parallel [
(call (mem:QI (symbol_ref:SI ("__main") [flags 0x41]) [0 S1 A8])
(const_int 0 [0x0]))
(clobber (reg:SI 31 r31))
]) -1 (nil)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
;; End of basic block 0, registers live:
(nil)
;; Start of basic block 1, registers live: (nil)
(note 7 5 8 1 [bb 1] NOTE_INSN_BASIC_BLOCK)
(insn 8 7 9 1 (set (reg:SI 108)
(reg/f:SI 29 r29)) -1 (nil)
(nil))
(insn 9 8 11 1 (set (reg:SI 70 [ saved_stack3 ])
(reg:SI 108)) -1 (nil)
(nil))
(insn 11 9 12 1 (set (reg/f:SI 109)
(symbol_ref:SI ("c") [flags 0x2] )) -1 (nil)
(nil))
(insn 12 11 13 1 (set (reg:HI 106 [ c0 ])
(mem/c/i:HI (reg/f:SI 109) [0 c+0 S2 A16])) -1 (nil)
(nil))
(insn 13 12 14 1 (set (reg:SI 105 [ D.1199 ])
(sign_extend:SI (reg:HI 106 [ c0 ]))) -1 (nil)
(nil))
(insn 14 13 15 1 (set (reg:SI 104 [ D.1200 ])
(plus:SI (reg:SI 105 [ D.1199 ])
(const_int -1 [0x]))) -1 (nil)
(nil))
(insn 15 14 16 1 (set (reg:SI 103 [ D.1201 ])
(reg:SI 104 [ D.1200 ])) -1 (nil)
(nil))
(insn 16 15 19 1 (set (reg:SI 102 [ D.1202 ])
(sign_extend:SI (reg:HI 106 [ c0 ]))) -1 (nil)
(nil))
(insn 19 16 17 1 (clobber (reg:DI 101 [ D.1203 ])) -1 (nil)
(insn_list:REG_LIBCALL 18 (nil)))
(insn 17 19 18 1 (set (subreg:SI (reg:DI 101 [ D.1203 ]) 4)
(reg:SI 102 [ D.1202 ])) -1 (nil)
(expr_list:REG_NO_CONFLICT (reg:SI 102 [ D.1202 ])
(nil)))
(insn 18 17 22 1 (set (subreg:SI (reg:DI 101 [ D.1203 ]) 0)
(const_int 0 [0x0])) -1 (nil)
(insn_list:REG_RETVAL 19 (expr_list:REG_NO_CONFLICT (reg:SI 102 [ D.1202 ])
(nil
(insn 22 18 20 1 (clobber (reg:DI 110)) -1 (nil)
(insn_list:REG_LIBCALL 21 (nil)))
(insn 20 22 21 1 (set (subreg:SI (reg:DI 110) 0)
(and:SI (subreg:SI (reg:DI 101 [ D.1203 ]) 0)
(const_int 15 [0xf]))) -1 (nil)
(expr_list:REG_NO_CONFLICT (reg:DI 101 [ D.1203 ])
(nil)))
(insn 21 20 25 1 (set (subreg:SI (reg:DI 110) 4)
(and:SI (subreg:SI (reg:DI 101 [ D.1203 ]) 4)
(const_int -1 [0x]))) -1 (nil)
(insn_list:REG_RETVAL 22 (expr_list:REG_NO
Re: GCC 4.2 branch comparision failure building Java
"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > This is caused by --enable-generated-files-in-srcdir, as used by the > release script, hence not being seen by people configuring normally > without that option. The first time Java is built (stage 2), the file > java/parse.c is generated in the build directory and compiled from the > build directory; only some time after parse.o is built does parse.c get > copied to the source directory. The second time (stage 3) it's built from > the source directory because of the VPATH setting. Building from > different paths means different debug info. > > This didn't apply with 4.1 because then, without toplevel bootstrap, all > files to be copied to the source directory were generated and copied in > stage 1, so stage 2 and stage 3 both built them from the source directory. > Now, stage 1 is not only built as C only but the whole stage 1 build > directory is configured as C only, and so Java generated files don't get > copied until stage 2. > > I have no suggested solution, other than ceasing to include files > generated with bison, flex and makeinfo in releases for 4.2 and later. > (The GNU Coding Standards describe such generated files with "We commonly > include" rather than with a requirement to include them.) Interesting. Since we require GNU make, we could do something along these lines: $(srcdir)/java/parse.c: java/parse.c -cp -p $^ $(srcdir)/java java.srcextra: $(srcdir)/java/parse.c ifeq ($(GENINSRC),) java/parse.o: $(srcdir)/java/parse.c else java/parse.o: java/parse.c endif The generated files have disappeared from mainline, so this would be a 4.2 only hack. Ian
Re: GCC 4.2 branch comparision failure building Java
Ian Lance Taylor wrote: > "Joseph S. Myers" <[EMAIL PROTECTED]> writes: > >> This is caused by --enable-generated-files-in-srcdir, as used by the >> release script, hence not being seen by people configuring normally >> without that option. Thanks for the analysis! > Since we require GNU make, we could do something along these lines: > > $(srcdir)/java/parse.c: java/parse.c > -cp -p $^ $(srcdir)/java > java.srcextra: $(srcdir)/java/parse.c > > ifeq ($(GENINSRC),) > java/parse.o: $(srcdir)/java/parse.c > else > java/parse.o: java/parse.c > endif I was thinking about trying to fix this by doing something similar -- but avoiding the copy. Can we do: java_parse_c := java/parse.c ifeq ($(GENINSRC),) java_parse_c := $(srcdir)/$(java_parse_c) endif $(java_parse_c): java/parse.y -$(BISON) -t ... -o $@ $< And, then, just have java/parse.o depend on $(java_parse_c)? I was going to give this a try, but if you know whether it's going to break, let me know. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2 branch comparision failure building Java
Mark Mitchell <[EMAIL PROTECTED]> writes: > Ian Lance Taylor wrote: > > "Joseph S. Myers" <[EMAIL PROTECTED]> writes: > > > >> This is caused by --enable-generated-files-in-srcdir, as used by the > >> release script, hence not being seen by people configuring normally > >> without that option. > > Thanks for the analysis! Yes indeed, that was somewhat tricky. > Can we do: > > java_parse_c := java/parse.c > ifeq ($(GENINSRC),) > java_parse_c := $(srcdir)/$(java_parse_c) > endif > > $(java_parse_c): java/parse.y > -$(BISON) -t ... -o $@ $< > > And, then, just have java/parse.o depend on $(java_parse_c)? That is a better plan. It seems like it ought to work. Ian
Re: GCC 4.2 branch comparision failure building Java
> This didn't apply with 4.1 because then, without toplevel bootstrap, all > files to be copied to the source directory were generated and copied in > stage 1, so stage 2 and stage 3 both built them from the source directory. > Now, stage 1 is not only built as C only but the whole stage 1 build > directory is configured as C only, and so Java generated files don't get > copied until stage 2. IIUC, the problem only manifests while *building* the release candidates, not for users of the release candidate. For 4.2, my suggestion is to just use a bootstrap4 while building the RC. For 4.3, we can use --enable-stage1-languages=all when building the RCs. I can prepare a patch to do that automatically when --enable-generated-files-in-srcdir is passed. Paolo
RFC: obsolete __builtin_apply?
I have long been annoyed by the failure of the test builtin-apply4.c on IA64 HP-UX and I know there are failures of tests using __builtin_apply on other platforms as well. My question is: Is it time to obsolete __builtin_apply, __builtin_apply_args, and __builtin_return? It looks like the main sticking point is that libobjc uses __builtin_apply, __builtin_apply_args, and __builtin_return. There is a FIXME comment about changing this to use libffi. Do any of the objc folks have this on their 'todo' plate? I am not sure how big this task would be. My thinking is that if libobjc was changed then we could put in a depreciated message on these builtins for 4.3 and maybe remove them for 4.4. Comments? Steve Ellcey [EMAIL PROTECTED]
Re: GCC 4.2 branch comparision failure building Java
On Fri, 16 Mar 2007, Mark Mitchell wrote: > I was thinking about trying to fix this by doing something similar -- > but avoiding the copy. You still need the srcextra rule around to do the copy, for use in generating gcc.pot without --egfis - or the regeneration instructions could change to require that option, which might be simpler. -- Joseph S. Myers [EMAIL PROTECTED]
Re: GCC 4.2 branch comparision failure building Java
Paolo Bonzini wrote: > IIUC, the problem only manifests while *building* the release candidates, > not for users of the release candidate. > > For 4.2, my suggestion is to just use a bootstrap4 while building the RC. That's an attractive idea. But, I'd rather fix it correctly, because distributors may run into the same problem. > For 4.3, we can use --enable-stage1-languages=all when building the RCs. > I can prepare a patch to do that automatically when > --enable-generated-files-in-srcdir > is passed. That might work, but it seems like overkill; that just makes the bootstrap process longer. My preferred solution would be to remove --e-g-f-i-s. I think we should just require that users have the tools they need to build the compilers, and drop all of this complexity. However, I recognize that's probably not the consensus opinion. Assuming that we can't do that, I'd rather just fix the Makefiles, if there are any more such problems. As Joseph's noted, the Java problem is already gone on mainline, thanks to the ECJ integration. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: obsolete __builtin_apply?
On 3/16/07, Steve Ellcey <[EMAIL PROTECTED]> wrote: My thinking is that if libobjc was changed then we could put in a depreciated message on these builtins for 4.3 and maybe remove them for 4.4. libobjc has not changed yet. There was a patch a while back to change libobjc to use libffi but I need to go back to it and review it (as it was before I became a libobjc maintainer). -- Pinski
Re: RFC: obsolete __builtin_apply?
On 3/16/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: On 3/16/07, Steve Ellcey <[EMAIL PROTECTED]> wrote: > My thinking is that if libobjc was changed then we could put in a > depreciated message on these builtins for 4.3 and maybe remove them for > 4.4. libobjc has not changed yet. There was a patch a while back to change libobjc to use libffi but I need to go back to it and review it (as it was before I became a libobjc maintainer). Do you mean this patch: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00841.html ? Gr. Steven
Re: GCC 4.2 branch comparision failure building Java
Paolo Bonzini wrote: For 4.3, we can use --enable-stage1-languages=all when building the RCs. I can prepare a patch to do that automatically when --enable-generated-files-in-srcdir is passed. That should not be needed on the trunk, as the .y files in question (gcc/java/parse.y and gcc/java/parse-scan.y) do not exist on the trunk. They have been removed. David Daney
gcc-4.3-20070316 is now available
Snapshot gcc-4.3-20070316 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070316/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 122999 You'll find: gcc-4.3-20070316.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070316.tar.bz2 C front end and core compiler gcc-ada-4.3-20070316.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070316.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070316.tar.bz2 C++ front end and runtime gcc-java-4.3-20070316.tar.bz2 Java front end and runtime gcc-objc-4.3-20070316.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070316.tar.bz2The GCC testsuite Diffs from 4.3-20070309 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: RFC: obsolete __builtin_apply?
On 3/16/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: Do you mean this patch: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00841.html Yes, thanks for finding the patch. I will look over it this weekend and apply it if it is good. -- Pinski
Building without bootstrapping
Hi , I am trying to build GCC without bootstrapping The config options I used were -- prefix= --disable-bootstrap --disable-libada --enable-languages=c I then did a make After that, I edited some code in c-parser.c , then, as suggested in http://gcc.gnu.org/ml/gcc/2007-02/msg00025.html , I tried make stage1-bubble This does not seem to compile the changed file. Please let me know what is the correct way to do this , also please point me to documentation that will help me understand the build process. -- Karthik
Re: Building without bootstrapping
"Karthikeyan M" <[EMAIL PROTECTED]> writes: > I am trying to build GCC without bootstrapping > > The config options I used were > > -- prefix= --disable-bootstrap --disable-libada --enable-languages=c > > I then did a > > make > > After that, I edited some code in c-parser.c , then, as suggested in > http://gcc.gnu.org/ml/gcc/2007-02/msg00025.html , I tried > > make stage1-bubble > > This does not seem to compile the changed file. "make stage1-bubble" works better if you don't use --disable-bootstrap when you run configure. If you do use --disable-bootstrap, just run "make all-gcc". There is some information here: http://gcc.gnu.org/wiki/Top-Level_Bootstrap Ian
Re: core changes for mep port
> > Sorry, I meant cgraph_mark_inline. It looks like what you want to > > me. But maybe I'm misreading it. > > And cgraph_check_inline_limits The magic place was cgraph_mark_inline_edges. Turns out, when I changed disallow_* to allow_*, I forgot to reverse the sense of the target's implementation, so it was omitting all the function calls but never printing a reason why :-P
Re: Building without bootstrapping
when you run configure. If you do use --disable-bootstrap, just run "make all-gcc". I tried this, it is still using the compiled-compiler in stage2 and beyond I added some code to c-parser.c and this crashes the built-compiler when it tries to compile itself. I want the build to stop after stage 1 , so that I can use gdb on cc1 to debug the problem . Basically, I am looking for a way to get the Makefile to always use only the system's pre-built gcc . Any help would be greatly appreciated. -- Karthik
Re: Building without bootstrapping
On Mar 16, 2007, at 6:51 PM, Karthikeyan M wrote: when you run configure. If you do use --disable-bootstrap, just run "make all-gcc". I tried this, it is still using the compiled-compiler in stage2 and beyond There is no stage 2 if you aren't bootstrapping. I'd recommend rm - rf build and start again. cd gcc && make would be the canonical development method.
Re: GCC 4.2 branch comparision failure building Java
Mark Mitchell wrote: > Paolo Bonzini wrote: > >> IIUC, the problem only manifests while *building* the release candidates, >> not for users of the release candidate. >> >> For 4.2, my suggestion is to just use a bootstrap4 while building the RC. > > That's an attractive idea. But, I'd rather fix it correctly, because > distributors may run into the same problem. Sorry, I meant 4.2.0 -- for 4.2.1, we can backport whatever fix is needed for 4.3. >> For 4.3, we can use --enable-stage1-languages=all when building the RCs. >> I can prepare a patch to do that automatically when >> --enable-generated-files-in-srcdir >> is passed. > > That might work, but it seems like overkill; that just makes the > bootstrap process longer. It makes it longer by one-two minutes: the time to build the three front-ends without optimization. Paolo
