Re: 4.1.0-RC{1,2} installs headers to /include
Hi, On Tuesday 28 February 2006 22:30, René Rebe wrote: > Hi, > > On Tuesday 28 February 2006 20:54, Mark Mitchell wrote: > > > > gxx_include_dir = $(libsubdir)/include/c++ > > > > That's the problem, then; there's no definition of libsubdir in that > > Makefile. What happens if you provide the explicit > > --with-gxx-include-dir option? > > > > I'm not sure when this was broken, but clearly the Java Makefile.am is > > incorrect; users of TL_AC_GXX_INCLUDE_DIR must define libsubdir. > > Yes, then it is: > > gxx_include_dir = /usr/include > > Though despite ccache and a Turion with 1.2GB RAM I'm still waiting > for "make instal" and the list of installed files ,-) As expected the headers are in the correct location now. Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45
tracking pointers in hardware
Hi all, I'm designing a new hardware that needs to know which GPR contains a simple integer, and which contained pointer. The hardware simply needs different load operations for both (we're talking load/store machines, with no indirect addressing to make life easier). From the compiler's perspective, all it needs is to annotate load operations to tell the hardware if this is a pointer or an integer (say LD for integers and PLD for pointers). As far as I can see, this data is not available in the final RTL stage: the RTL contains some pointer data about virtual registers at first, but it seems this data gets lost during optimizations, and mainly during the reload phase. Do any of you guys have suggestions how to implement it as part of gcc? My only idea for now is to add an RTL pass just before the final pass tracking dataflow to find which registers are used as addresses in loads/stores (but this can probably be done by dataflow tracking asm-to-asm filter). Thanks, Yoav Etsion
mips-elf-linux and mips-linux-elf, another puzzler
Hi, After talking about mips-elf, mips-linux, mips-elf-linux-gnu, my friend told that there is also a target of mips-linux-elf. My God, confused. Yours, Eric.
Re: mips-elf-linux and mips-linux-elf, another puzzler
On Mar 1, 2006, at 1:43 AM, Eric Fisher wrote: Hi, After talking about mips-elf, mips-linux, mips-elf-linux-gnu, my friend told that there is also a target of mips-linux-elf. My God, confused. Ignore your friend. -eric
Re: Preserving bootstrap with non-GCC compilers
Eric Botcazou <[EMAIL PROTECTED]> writes: [...] | Comments? Go for it! -- Gaby
Re: Libjava (gij) testting on the mainline
Andrew Pinski writes: > With clean sources on x86_64-linux-gnu, I am getting almost all tests > for running gij to fail. Does anyone know what is going on here? I'll have a try now. Andrew.
Re: Bootstrap failure on trunk: x86_64-linux-gnu
Jeffrey A Law wrote: > I wouldn't have a problem with non-canonical bounds if there were > no way to get a value into an object which is outside the > bounds. But if we can get values into the object which are outside > those bounds, then either the bounds are incorrect or the program > is invalid. > I would classify this as a gimplification bug, as the starting program is correct, but the GIMPLE form is not. GIMPLE was introduced for reducing the complexity of the specific of each language, so I think that the types should also be translated to a canonical form. Sebastian
problem with the gcc 3.4.4
Hi, I have a problem with the compiler gcc 3.4.4. With the gcc 3.2 compiler, i have no problem with the following instruction : creal(U0[i])=PartieReelle; cimag(U0[i])=PartieImaginaire; Now with the gcc 3.4.4 i have the folowing message : -- erreur: invalid lvalue in assignment -- erreur: invalid lvalue in assignment Sincerly yours. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Libjava (gij) testting on the mainline
Andrew Haley writes: > Andrew Pinski writes: > > With clean sources on x86_64-linux-gnu, I am getting almost all tests > > for running gij to fail. Does anyone know what is going on here? > > I'll have a try now. You are right. The error is lt-gij: relocation error: /home/aph/gcc/trunk/build-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/.libs/libgcj.so.7: symbol _Unwind_GetIPInfo, version GCC_4.2.0 not defined in file libgcc_s.so.1 with link time reference The problem is that gij has a hard-coded rpath to the install dir: [EMAIL PROTECTED] libjava]$ readelf -d .libs/lt-gij Dynamic section at offset 0x830 contains 27 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libgij.so.7] 0x0001 (NEEDED) Shared library: [libgcj.so.7] 0x0001 (NEEDED) Shared library: [libpthread.so.0] 0x0001 (NEEDED) Shared library: [libdl.so.2] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x000f (RPATH) Library rpath: [/home/aph/gcc/trunk/build-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/.libs:/home/aph/gcc/install/lib/../lib64] Running `make install' fixes it. :-( Andrew.
Re: Bootstrap failure on trunk: x86_64-linux-gnu
On Tue, 2006-02-28 at 18:59 -0500, Daniel Jacobowitz wrote: > On Tue, Feb 28, 2006 at 03:40:37PM -0700, Jeffrey A Law wrote: > > Here's a great example from uintp.adb (which is the cause of the > > testsuite hang FWIW) > > > > We have a loop with the following termination code in uintp.num_bits > > > > # BLOCK 8 > > # PRED: 5 [100.0%] (fallthru,exec) 6 (fallthru,dfs_back,exec) > > # num_2 = PHI ; > > # bits_1 = PHI ; > > :; > > num.265_5 = (types__TintB) num_2; > > if (num.265_5 <= 0) goto ; else goto ; > > # SUCC: 7 (true,exec) 6 (false,exec) > > ... > > > So, why am I bringing this up? Because num can actually have > > the value 0x8000 at runtime, which is out of its type's > > MIN/MAX range. And what do you think happens? Well, given the > > (valid) simplification of the loop test and the way "num" is > > assigned within the loop (num = num / 2), the loop never terminates. > > I've been following this entire thread, and I think there's a serious > disconnect between the parties - it's unfortunate that none of the > tree-ssa folks involved know Ada as I suspect that would straighten > it out in a hurry. This is a perfect example. Now that we have some > concrete code that's causing a problem, let's take a look at it > (bear in mind, I don't know Ada either): > >function Num_Bits (Input : Uint) return Nat is > Bits : Nat; > Num : Nat; > >begin > if UI_Is_In_Int_Range (Input) then > Num := abs (UI_To_Int (Input)); > Bits := 0; > > else > Bits := Base_Bits * (Uints.Table (Input).Length - 1); > Num := abs (Udigits.Table (Uints.Table (Input).Loc)); > end if; > > while Types.">" (Num, 0) loop > Num := Num / 2; > Bits := Bits + 1; > end loop; > > return Bits; >end Num_Bits; The specifications in uintp.ads says: function Num_Bits (Input : Uint) return Nat; -- Approximate number of binary bits in given universal integer. -- This function is used for capacity checks, and it can be one -- bit off without affecting its usage. So this is a hint function, anything not hanging should do, like if UI_Is_In_Int_Range (Input) then return Nat'Size; else ... > I'm going to assume that UI_Is_In_Int_Range isn't true for 0x8000. > The other case is still assigning 0x8000 to Nat somehow. I'd be > amazed if that's really valid Ada! Could someone who knows the > language comment, please? Ada checks are off when compiling the FE, in full Ada you should get a Constraint_Error on the abs line on int'first. You should get an exception it if you put a pragma Unsuppress (All_Checks); before begin. So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface issue, thanks for spotting this! Laurent
Re: gcc 4.1.0 NOT built on i686-pc-linux-gnu (Scientific Linux 3.0.4)
On Mar 1, 2006, at 2:43 AM, Maurizio Loreti wrote: /usr/soft/lib/libmpfr.a(set_str.o): In function `mpfr_set_str': set_str.c:(.text+0x174): undefined reference to `__ctype_b' set_str.c:(.text+0x3b5): undefined reference to `__ctype_b' set_str.c:(.text+0x411): undefined reference to `__ctype_b' This means your libmpfr.a was compiled for the wrong glibc. Thanks, Andrew Pinski
Re: Bootstrap failure on trunk: x86_64-linux-gnu
So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface issue, thanks for spotting this! Indeed, having looked a bit closer at Uintp, I think this is the right fix. Robert, please confirm. *** uintp.adb 12 Sep 2003 21:50:56 - 1.80 --- uintp.adb 1 Mar 2006 13:08:06 - *** package body Uintp is *** 591,595 begin ! if UI_Is_In_Int_Range (Input) then Num := abs (UI_To_Int (Input)); Bits := 0; --- 591,598 begin ! if Input = Uint_Int_First then ! Num := Int'Size; ! ! elsif UI_Is_In_Int_Range (Input) then Num := abs (UI_To_Int (Input)); Bits := 0;
Re: Libjava (gij) testting on the mainline
On Mar 1, 2006, at 6:48 AM, Andrew Haley wrote: Andrew Haley writes: Andrew Pinski writes: With clean sources on x86_64-linux-gnu, I am getting almost all tests for running gij to fail. Does anyone know what is going on here? I'll have a try now. You are right. The error is lt-gij: relocation error: /home/aph/gcc/trunk/build-x86_64-unknown-linux-gnu/x86_64-unknown- linux-gnu/libjava/.libs/libgcj.so.7: symbol _Unwind_GetIPInfo, version GCC_4.2.0 not defined in file libgcc_s.so.1 with link time reference Running `make install' fixes it. :-( That only fixed some of the failures. The rest are like: Exception in thread "main" java.lang.NoClassDefFoundError: bytebuffer at java.lang.Class.initializeClass (natClass.cc:691) at java.lang.Class.forName (Class.h:624) at gnu.java.lang.MainThread.run (MainThread.java:95) Caused by: java.lang.VerifyError: verification failed at PC 3 in bytebuffer:main(([Ljava.lang.String;)V): incompatible type on stack at java.lang.Class.initializeClass (natClass.cc:685) ...2 more FAIL: bytebuffer execution - gij test And I just doubled checked to make sure I don't have CLASSPATH set. -- Pinski
Re: Bootstrap failure on trunk: x86_64-linux-gnu
So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface issue, thanks for spotting this! Sorry, my last suggestion is clearly wrong. I think is right. *** uintp.adb 12 Sep 2003 21:50:56 - 1.80 --- uintp.adb 1 Mar 2006 13:16:21 - *** package body Uintp is *** 591,595 begin ! if UI_Is_In_Int_Range (Input) then Num := abs (UI_To_Int (Input)); Bits := 0; --- 591,598 begin ! if Input = Uint_Int_First then ! return Int'Size; ! ! elsif UI_Is_In_Int_Range (Input) then Num := abs (UI_To_Int (Input)); Bits := 0;
Re: gcc 4.1.0 NOT built on i686-pc-linux-gnu (Scientific Linux 3.0.4)
On Wed, 1 Mar 2006, Andrew Pinski wrote: This means your libmpfr.a was compiled for the wrong glibc. Thanks for the hint -- now I have completed the 4.1.0 build/install, with [EMAIL PROTECTED] 19 $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1.0/configure --prefix=/usr/soft/gcc4 --with-mpfr=/usr/soft --with-gmp=/usr/soft --enable-languages=c,c++,fortran Thread model: posix gcc version 4.1.0 My problem was that I manage a cluster of several gnu-linux machines, where the user may choose between gcc 4.1.0 and 3.4.5 executing shell scripts. As you guessed, libmpfr.a has been compiled against an old glibc (2.2.5) where the PC used for "make bootstrap" had glibc 2.3.2 . Many thanks for the help, and thank for maintaining gcc. -- Maurizio Loreti http://www.pd.infn.it/~loreti/mlo.html Un. of Padova, Dept. of Physics - Padova, Italy[EMAIL PROTECTED]
Re: Libjava (gij) testting on the mainline
On Tue, Feb 28, 2006 at 08:40:18PM -0500, Andrew Pinski wrote: > With clean sources on x86_64-linux-gnu, I am getting almost all tests > for running gij to fail. Does anyone know what is going on here? I will bet it is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311 H.J.
PATCH: Libjava (gij) testting on the mainline
On Wed, Mar 01, 2006 at 11:48:39AM +, Andrew Haley wrote: > Andrew Haley writes: > > Andrew Pinski writes: > > > With clean sources on x86_64-linux-gnu, I am getting almost all tests > > > for running gij to fail. Does anyone know what is going on here? > > > > I'll have a try now. > > You are right. The error is > > lt-gij: relocation error: > /home/aph/gcc/trunk/build-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/.libs/libgcj.so.7: > symbol _Unwind_GetIPInfo, version GCC_4.2.0 not defined in file > libgcc_s.so.1 with link time reference > > The problem is that gij has a hard-coded rpath to the install dir: > > [EMAIL PROTECTED] libjava]$ readelf -d .libs/lt-gij > > Dynamic section at offset 0x830 contains 27 entries: > TagType Name/Value > 0x0001 (NEEDED) Shared library: [libgij.so.7] > 0x0001 (NEEDED) Shared library: [libgcj.so.7] > 0x0001 (NEEDED) Shared library: [libpthread.so.0] > 0x0001 (NEEDED) Shared library: [libdl.so.2] > 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] > 0x0001 (NEEDED) Shared library: [libc.so.6] > 0x0001 (NEEDED) Shared library: [libm.so.6] > 0x000f (RPATH) Library rpath: > [/home/aph/gcc/trunk/build-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/.libs:/home/aph/gcc/install/lib/../lib64] > > Running `make install' fixes it. :-( > The fix was posted at http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html H.J.
Re: PATCH: Libjava (gij) testting on the mainline
H. J. Lu writes: > On Wed, Mar 01, 2006 at 11:48:39AM +, Andrew Haley wrote: > > Andrew Haley writes: > > > Andrew Pinski writes: > > > > With clean sources on x86_64-linux-gnu, I am getting almost all > > tests > > > > for running gij to fail. Does anyone know what is going on here? > > > > > > I'll have a try now. > > > > You are right. The error is > > > > lt-gij: relocation error: > > /home/aph/gcc/trunk/build-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/.libs/libgcj.so.7: > > symbol _Unwind_GetIPInfo, version GCC_4.2.0 not defined in file > > libgcc_s.so.1 with link time reference > > > > The problem is that gij has a hard-coded rpath to the install dir: > > > > [EMAIL PROTECTED] libjava]$ readelf -d .libs/lt-gij > > > > Dynamic section at offset 0x830 contains 27 entries: > > TagType Name/Value > > 0x0001 (NEEDED) Shared library: [libgij.so.7] > > 0x0001 (NEEDED) Shared library: [libgcj.so.7] > > 0x0001 (NEEDED) Shared library: [libpthread.so.0] > > 0x0001 (NEEDED) Shared library: [libdl.so.2] > > 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] > > 0x0001 (NEEDED) Shared library: [libc.so.6] > > 0x0001 (NEEDED) Shared library: [libm.so.6] > > 0x000f (RPATH) Library rpath: > > [/home/aph/gcc/trunk/build-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/.libs:/home/aph/gcc/install/lib/../lib64] > > > > Running `make install' fixes it. :-( > > > > The fix was posted at > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html If it still works, please check it in. Andrew.
Re: iWMMXt/Linux EABI toolchain
On Wed, Mar 01, 2006 at 05:15:07AM +, Steven Newbury wrote: > I have managed to build with arm-iwmmxt-linux-gnu, where iwmmxt as the vendor > string is picked up by my ebuild scripts to pass the iwmmxt target flags. > Given my objective, am I wrong to try to make a tool chain that targets > xscale-iwmmxt-linux-gnueabi specifically or do you just consider it > unnecessary > effort? I don't think there's any point to the xscale-* triplets nowadays. -- Daniel Jacobowitz CodeSourcery
Marking a builtin function as `noreturn'.
Hi all, I maintain a port of gcc for an embedded processor which has a HALT instruction. This instruction stops the processor, and generates an appropriate interrupt to indicate to its parent system that it has stopped. The instruction is accessed by the programmer using a port-specific builtin, which can then be used, amongst other things, to implement the `assert' macro. At the moment, whenever a HALT instruction is emitted, the compiler still seems to assume that execution will continue after the HALT instruction has executed (e.g., the compiler emits branches to the function epilogue, etc.). I would like the compiler to treat the builtin instruction as though it had the attribute `noreturn'. I have added this attribute to the builtin declaration in the TARGET_INIT_BUILTINS function, but it appears to make no difference. I may have got the code wrong, but assuming the code is correct, should gcc allow a builtin to be marked as a noreturn? Should a builtin marked in this way stop any code flow after the HALT? Is there another way to achieve the effect I am after? Thanks, dan. -- Daniel Towner picoChip Designs Ltd, Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG [EMAIL PROTECTED] +44 (0) 7786 702589
Re: Marking a builtin function as `noreturn'.
> > Hi all, > > I maintain a port of gcc for an embedded processor which has a HALT > instruction. This instruction stops the processor, and generates an > appropriate interrupt to indicate to its parent system that it has > stopped. The instruction is accessed by the programmer using a > port-specific builtin, which can then be used, amongst other things, to > implement the `assert' macro. Why doesn't this HALT instruction map directly to the trap builtin? Isn't that a better way of doing it then using a port specific builtin? -- Pinski
Re: PATCH: Libjava (gij) testting on the mainline
On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote: > H. J. Lu writes: > > On Wed, Mar 01, 2006 at 11:48:39AM +, Andrew Haley wrote: > > > Andrew Haley writes: > > > > Andrew Pinski writes: > > > > > With clean sources on x86_64-linux-gnu, I am getting almost all > tests > > > > > for running gij to fail. Does anyone know what is going on here? > > > > > > > > I'll have a try now. > > > > > > You are right. The error is > > > > > > lt-gij: relocation error: > /home/aph/gcc/trunk/build-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/.libs/libgcj.so.7: > symbol _Unwind_GetIPInfo, version GCC_4.2.0 not defined in file > libgcc_s.so.1 with link time reference > > > > > > The problem is that gij has a hard-coded rpath to the install dir: > > > > > > [EMAIL PROTECTED] libjava]$ readelf -d .libs/lt-gij > > > > > > Dynamic section at offset 0x830 contains 27 entries: > > > TagType Name/Value > > > 0x0001 (NEEDED) Shared library: [libgij.so.7] > > > 0x0001 (NEEDED) Shared library: [libgcj.so.7] > > > 0x0001 (NEEDED) Shared library: > [libpthread.so.0] > > > 0x0001 (NEEDED) Shared library: [libdl.so.2] > > > 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] > > > 0x0001 (NEEDED) Shared library: [libc.so.6] > > > 0x0001 (NEEDED) Shared library: [libm.so.6] > > > 0x000f (RPATH) Library rpath: > [/home/aph/gcc/trunk/build-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/.libs:/home/aph/gcc/install/lib/../lib64] > > > > > > Running `make install' fixes it. :-( > > > > > > > The fix was posted at > > > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html > > If it still works, please check it in. Ooops. The correct patch is http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00663.html for ltmain.sh. Libtool is braindead when libgcc_s is involved. Should I check it in once it is verified? H.J.
Re: PATCH: Libjava (gij) testting on the mainline
H. J. Lu writes: > On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote: > > H. J. Lu writes: > > > > > > The fix was posted at > > > > > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html > > > > If it still works, please check it in. > > Ooops. The correct patch is > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00663.html > > for ltmain.sh. Libtool is braindead when libgcc_s is involved. Should > I check it in once it is verified? That doesn't look right: we _need_ the rpath for gij to be in the install dir. Andrew.
Re: PATCH: Libjava (gij) testting on the mainline
On Wed, Mar 01, 2006 at 03:19:18PM +, Andrew Haley wrote: > H. J. Lu writes: > > On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote: > > > H. J. Lu writes: > > > > > > > > The fix was posted at > > > > > > > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html > > > > > > If it still works, please check it in. > > > > Ooops. The correct patch is > > > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00663.html > > > > for ltmain.sh. Libtool is braindead when libgcc_s is involved. Should > > I check it in once it is verified? > > That doesn't look right: we _need_ the rpath for gij to be in the install dir. There are 2 gij, one for installation and one for build. We do want the installed dir in the rpath of the installed gij. But we don't want it in the rpath of the gij used for build. My patch only removes the installed dir from the rpath of the gij used for build. The rpath of the installed gij is unchanged. H.J.
Re: PATCH: Libjava (gij) testting on the mainline
H. J. Lu writes: > On Wed, Mar 01, 2006 at 03:19:18PM +, Andrew Haley wrote: > > H. J. Lu writes: > > > On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote: > > > > H. J. Lu writes: > > > > > > > > > > The fix was posted at > > > > > > > > > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html > > > > > > > > If it still works, please check it in. > > > > > > Ooops. The correct patch is > > > > > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00663.html > > > > > > for ltmain.sh. Libtool is braindead when libgcc_s is involved. Should > > > I check it in once it is verified? > > > > That doesn't look right: we _need_ the rpath for gij to be in the install > > dir. > > There are 2 gij, one for installation and one for build. We do want > the installed dir in the rpath of the installed gij. But we don't want > it in the rpath of the gij used for build. My patch only removes > the installed dir from the rpath of the gij used for build. The rpath > of the installed gij is unchanged. That's OK, then. Andrew.
Re: iWMMXt/Linux EABI toolchain
On Wednesday 01 March 2006 05:05, Daniel Jacobowitz wrote: > On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote: > > Thanks for the quick response! > > I'm sure it seems I like to make hard wok for myself! It gets worse, I'm > > porting Gentoo Linux to iWMMXt with pure EABI kernel and userspace. I'm > > not concerned about being able to run old binaries. So is using > > abi=iwmmxt really not what I want? A really bad idea? > > Absolutely. You want the AAPCS, not Intel's pre-AAPCS ABI. Actually, -mabi=iwmmxt is AAPCS based. It's diffferent from the old intel iwmmxt ABI. Having said that, it probably hasn't been tested particularly well, and I wouldn't advise using it unless you really need it (ie. you know you have performace sensitive code that makes extensive use of iWMMXt vector types in function arguments). Paul
Re: Marking a builtin function as `noreturn'.
Hi Andrew, The problem with calling __builtin_trap directly comes when several traps are called in the same function. For example, if a function contains several identical assertions on different code paths, then gcc will generate a single copy of the assertion, and branch to that copy from each of the original assertion sites. If an assertion is hit, it becomes impossible to tell which of the original source assertions this relates to. Note that this is an embedded processor, so the source line, error description and so on can't be embedded in the assertion, since that consumes too much space; all an assertion does is test the condition, and possibly call the HALT. I defined my own builtin to access the HALT, in such a way that every time a HALT instruction is generated, it is assigned a unique id. This id does nothing (it just generates a comment in the assembly output), but its presence is enough to fool the compiler into treating identical source assertions as though they were different. This means that the different assertions get their own HALT's, and if a HALT is detected at runtime, the debugger can easily determine which source assertion this relates to. Thanks, dan. I maintain a port of gcc for an embedded processor which has a HALT instruction. This instruction stops the processor, and generates an appropriate interrupt to indicate to its parent system that it has stopped. The instruction is accessed by the programmer using a port-specific builtin, which can then be used, amongst other things, to implement the `assert' macro. Why doesn't this HALT instruction map directly to the trap builtin? Isn't that a better way of doing it then using a port specific builtin? -- Pinski -- Daniel Towner picoChip Designs Ltd, Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG [EMAIL PROTECTED] +44 (0) 7786 702589
Re: Inconsistency in ix86_binary_operator_ok?
>My confusion is that these functions currently allow arithmetic >operations of the form "reg = op(mem,immed)" even though this >shape isn't supported by x86 ISA. The IMUL instruction can have this form. Ross Ridge
GCC 4.1.0 Released
GCC 4.1.0 has been released. This release is a major release, containing substantial new functionality relative to previous releases. See: http://gcc.gnu.org/gcc-4.1/changes.html for a list of new features, improvements, and other changes. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in the gcc/gcc-4.1.0 subdirectory. There are two important caveats beyond those listed on the web page above: 1. GNU TAR 1.14 is required to unpack the source releases. Other versions of tar are likely to report errors or silently unpack the file incorrectly. 2. It was discovered after the final release had been made that there is an installation problem when building with Java enabled and when "--enable-version-specific-runtime-libs" is in use . In particular, header files for some of the Java APIs will be placed in "/include" (with no prefix), due to a defect in the Java Makefiles. There are three known work-arounds: a) Disable Java by using "--enable-languages" when configuring GCC. For example, to build just the C and C++ compilers, use "--enable-languages=c,c++". b) Do not use "--enable-version-specific-runtime-libs". c) Use "--with-gxx-include-dir=" to explicitly indicate where you would like the Java header files to be placed. For example, if you use "--prefix=/path/to/prefix" then using: --with-gxx-include-dir=/path/to/prefix/lib/gcc//4.1.0 will place the header files in the appropriate version-specific location. I expect this problem will be corrected in GCC 4.1.1. If you encounter any difficulties using GCC 4.1.0, please do not send them directly to me. Instead, please http://gcc.gnu.org/ for information about getting help and filing problem reports. We expect to release GCC 4.0.3 (an bug-fix release relative to GCC 4.0.2) in the near future. GCC 4.1.1 (a bug-fix release for GCC 4.1.0) will be released in approximately two months. As usual, a vast number of people contributed to this release -- far too many to thank by name! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Preserving bootstrap with non-GCC compilers
On Wed, 2006-03-01 at 08:15 +0100, Eric Botcazou wrote: > Hi, > > I'm a big fan of Zack's "over-my-dead-body" motto when it comes to ditching > bootstrap with non-GCC compilers. :-) It turns out that bootstrap is again > broken on mainline for them (at least Sun CC) and that the problem is another > instance of PR bootstrap/18058. Even though I don't mess with HP-UX anymore (and boy I'm a happier man for that!), I'm still a supporter of the ability to bootstrap with non-GCC compilers. > Given that the problem has already showed up at least twice and that there is > a straightforward way to mimic it with GCC, I'm proposing to be proactive and > add -fkeep-inline-functions to CFLAGS for stage1 of an --enable-bootstrap > build if the bootstrap compiler is a version of GCC that supports it. More > generally, if other bootstrap with non-GCC compilers issues pop up, I think > we should strive to emulate them with GCC. Seems quite reasonable to me. jeff
Re: Marking a builtin function as `noreturn'.
> > Hi Andrew, > > The problem with calling __builtin_trap directly comes when several > traps are called in the same function. For example, if a function > contains several identical assertions on different code paths, then gcc > will generate a single copy of the assertion, and branch to that copy > from each of the original assertion sites. If an assertion is hit, it > becomes impossible to tell which of the original source assertions this > relates to. Note that this is an embedded processor, so the source line, > error description and so on can't be embedded in the assertion, since > that consumes too much space; all an assertion does is test the > condition, and possibly call the HALT. Well the easy way around this is have a function which just does halt but sends the line number before halting. I don't see anyway around this really except taking up more space. -- Pinski
Re: 4.1.0-RC{1,2} installs headers to /include
René Rebe wrote: > As expected the headers are in the correct location now. Good. Have you filed a bug in Bugzilla about this issue? If not, would you care to do so? To do so, please visit gcc.gnu.org, and look for the link on the left side of the page. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: iWMMXt/Linux EABI toolchain
--- Paul Brook <[EMAIL PROTECTED]> wrote: > On Wednesday 01 March 2006 05:05, Daniel Jacobowitz wrote: > > On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote: > > > Thanks for the quick response! > > > I'm sure it seems I like to make hard wok for myself! It gets worse, I'm > > > porting Gentoo Linux to iWMMXt with pure EABI kernel and userspace. I'm > > > not concerned about being able to run old binaries. So is using > > > abi=iwmmxt really not what I want? A really bad idea? > > > > Absolutely. You want the AAPCS, not Intel's pre-AAPCS ABI. > > Actually, -mabi=iwmmxt is AAPCS based. It's diffferent from the old intel > iwmmxt ABI. > > Having said that, it probably hasn't been tested particularly well, and I > wouldn't advise using it unless you really need it (ie. you know you have > performace sensitive code that makes extensive use of iWMMXt vector types in > function arguments). My project is to build a complete system optimized for iWMMXt. I am expecting to have to do the odd bit of debugging when things break, so I'll be doing the testing..! Steve ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: iWMMXt/Linux EABI toolchain
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 05:15:07AM +, Steven Newbury wrote: > > I have managed to build with arm-iwmmxt-linux-gnu, where iwmmxt as the > vendor > > string is picked up by my ebuild scripts to pass the iwmmxt target flags. > > Given my objective, am I wrong to try to make a tool chain that targets > > xscale-iwmmxt-linux-gnueabi specifically or do you just consider it > unnecessary > > effort? > > I don't think there's any point to the xscale-* triplets nowadays. My reason for using the xscale-* triplets was because of the warning below from gcc/config/arm/t-xscale-elf: # The iWMMXt multilibs are suppressed for now because gcc only # supports generating them with the IWMMXT or AAPCS ABIs, neither of # which is the default. Until GCC can generate code for an iWMMXt # which will work with the default ABI it is not possible to safely # generate these multilibs. # Since I'm not going to be using the default ABI I thought I would be better off adding a specific target since my aim is to produce a complete Linux environment for general use rather than a stand-alone project. That way I could enable the iWMMXt multilibs without worrying about incompatibility with non iWMMXt targets. Perhaps I'd be better off using iwmmxt-*? Steve ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: iWMMXt/Linux EABI toolchain
On Wed, Mar 01, 2006 at 05:43:53PM +, Steven Newbury wrote: > My reason for using the xscale-* triplets was because of the warning below > from > gcc/config/arm/t-xscale-elf: > > # The iWMMXt multilibs are suppressed for now because gcc only > # supports generating them with the IWMMXT or AAPCS ABIs, neither of > # which is the default. Until GCC can generate code for an iWMMXt > # which will work with the default ABI it is not possible to safely > # generate these multilibs. > # > > Since I'm not going to be using the default ABI I thought I would be better > off > adding a specific target since my aim is to produce a complete Linux > environment for general use rather than a stand-alone project. That way I > could enable the iWMMXt multilibs without worrying about incompatibility with > non iWMMXt targets. Perhaps I'd be better off using iwmmxt-*? The comment does not apply to an EABI toolchain, which you are building. And comments about multilibs don't apply to anything using --with-cpu; if you're doing that you ought to be using --disable-multilib anyway. -- Daniel Jacobowitz CodeSourcery
re: GCC 4.1.0 Released
Mark wrote: > 1. GNU TAR 1.14 is required to unpack the source releases. Other > versions of tar are likely to report errors or silently unpack the > file incorrectly. Now hold on there, bubaloo. I thought the warnings from older versions of tar were benign. The warnings I'm seeing from tar-1.13.19 are tar: pax_global_header: Unknown file type 'g', extracted as normal file Searching for this error message, I find a quote from Linus Torvalds, (http://lkml.org/lkml/2005/6/18/5): >Yes, git creates tar-archives that use the extended pax headers, and I >think you need tar-1.14 to fully understand them. They should not hurt >(apart from the warning) on older versions of tar. > >The extended header just contains a hidden comment record that tells the >git commit ID that was used to generate the tar-tree. > >Because it's extracted as a regular file (instead of tar knowing that it's >a comment header), you will now have a file called "pax_global_header" >that has the contents > 52 comment=9ee1c939d1cb936b1f98e8d81aeffab57bae46ab > >in it (where "9ee1c939d1cb936b1f98e8d81aeffab57bae46ab" is the git SHA1 >name of the Linux-2.6.12 commit). > >So it's not entirely "harmless" in that it causes a bogus file to be >created, but it's not like it's a huge problem either, and that bogus file >actually does contain real information (although it's not useful unless >you're a git user). So perhaps the release notes should say 1. GNU TAR 1.14 is recommended to unpack the source releases. Other versions of tar may issue the warning tar: pax_global_header: Unknown file type 'g', extracted as normal file and/or silently create spurious files named 'pax_global_header'. These are artifacts reflecting the fact that the tarballs were created with git. Or something like that. Or is tar-1.14 really required? That would be highly annoying. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 10:05:52AM -0800, Dan Kegel wrote: > Mark wrote: > > 1. GNU TAR 1.14 is required to unpack the source releases. Other > > versions of tar are likely to report errors or silently unpack the > > file incorrectly. > > Now hold on there, bubaloo. > I thought the warnings from older versions of tar were benign. > The warnings I'm seeing from tar-1.13.19 are > tar: pax_global_header: Unknown file type 'g', extracted as normal file > Searching for this error message, I find a quote from Linus Torvalds, > (http://lkml.org/lkml/2005/6/18/5): The problem has nothing to do with warnings from tar, which are neither errors nor silent failures. I believe a file either got skipped or unpacked with the wrong name. > 1. GNU TAR 1.14 is recommended to unpack the source releases. Other > versions of tar may issue the warning > tar: pax_global_header: Unknown file type 'g', extracted as normal file > and/or silently create spurious files named 'pax_global_header'. > These are artifacts reflecting the fact that the tarballs were > created with git. The tarballs most certainly weren't created with git. -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.1.0 Released
On 3/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > > > 1. GNU TAR 1.14 is required to unpack the source releases. Other > > > versions of tar are likely to report errors or silently unpack the > > > file incorrectly. > > The problem has nothing to do with warnings from tar, which are neither > errors nor silent failures. I believe a file either got skipped or > unpacked with the wrong name. Egads. Can you point me to more info? I've been building with older versions of tar without any problem beyond the warnings. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 10:10:39AM -0800, Dan Kegel wrote: > On 3/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > > > > 1. GNU TAR 1.14 is required to unpack the source releases. Other > > > > versions of tar are likely to report errors or silently unpack the > > > > file incorrectly. > > > > The problem has nothing to do with warnings from tar, which are neither > > errors nor silent failures. I believe a file either got skipped or > > unpacked with the wrong name. > > Egads. Can you point me to more info? I've been building with older > versions of tar without any problem beyond the warnings. I don't know where the report was. I think it was on this list in the last week or two. -- Daniel Jacobowitz CodeSourcery
Re: iWMMXt/Linux EABI toolchain
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 05:43:53PM +, Steven Newbury wrote: > > My reason for using the xscale-* triplets was because of the warning below > from > > gcc/config/arm/t-xscale-elf: > > > > # The iWMMXt multilibs are suppressed for now because gcc only > > # supports generating them with the IWMMXT or AAPCS ABIs, neither of > > # which is the default. Until GCC can generate code for an iWMMXt > > # which will work with the default ABI it is not possible to safely > > # generate these multilibs. > > # > > > > Since I'm not going to be using the default ABI I thought I would be better > off > > adding a specific target since my aim is to produce a complete Linux > > environment for general use rather than a stand-alone project. That way I > > could enable the iWMMXt multilibs without worrying about incompatibility > with > > non iWMMXt targets. Perhaps I'd be better off using iwmmxt-*? > > The comment does not apply to an EABI toolchain, which you are > building. And comments about multilibs don't apply to anything > using --with-cpu; if you're doing that you ought to be using > --disable-multilib anyway. OK, thank-you. I'll target "arm-iwmmxt-linux-gnueabi" with --with-cpu= etc and --disable-multilib. The vendor string is for my build scripts and also will help differentiate the toolchain, is that valid? Steve ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: iWMMXt/Linux EABI toolchain
On Wed, Mar 01, 2006 at 06:20:53PM +, Steven Newbury wrote: > OK, thank-you. I'll target "arm-iwmmxt-linux-gnueabi" with --with-cpu= etc > and > --disable-multilib. The vendor string is for my build scripts and also will > help differentiate the toolchain, is that valid? Yep. -- Daniel Jacobowitz CodeSourcery
GCC-3.4.6 release status
Hi, A pre-release of GCC-3.4.6 is available at ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.6-20060301/ Please download and test. At the moment, there is only one issue I consider important for GCC-3.4.6. This is wrong code generation issue middle-end/24804. It was already present in GCC-3.4.4, GCC-3.4.5. If no "acceptable" fix can be found, then GCC-3.4.6 will also have it. GCC-3.4.6 will be the last release from the GCC-3.4 series. After that, the branch will be closed. -- Gabriel Dos Reis [EMAIL PROTECTED]
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 08:24:18AM -0800, Mark Mitchell wrote: > 1. GNU TAR 1.14 is required to unpack the source releases. Other >versions of tar are likely to report errors or silently unpack the >file incorrectly. Red Hat EL3 comes with tar 1.13.25 (though since the RPM package on the machine I used is 1.13.25-13, it's likely that Red Hat has applied some fixes to get up to rev 13). I unpacked gcc-4.1.0.tar.bz2 with both the Red Hat tar package and with the newest FSF tar (version 1.15.1). There were no warning messages, and diff -r reports that the two tars produce identical files. What is the basis for the report that older tars don't work?
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 08:24:18AM -0800, Mark Mitchell wrote: > > GCC 4.1.0 has been released. > It is great. Is 4.1 branch open now? I'd like to back port the x86 -mtune=generic patch: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01436.html to 4.1.1. Thanks. H.J.
GCC 4.1 branch open
The GCC 4.1 branch is now open, under the usual branch rules: fixes for regressions only. Remember: the GCC 4.0 branch will freeze at midnight tonight, GMT-8, in preparation for GCC 4.0.3. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.0 Released
On Wednesday 01 March 2006 21:14, H. J. Lu wrote: > Is 4.1 branch open now? I'd like to back port the x86 > -mtune=generic patch: Isn't that totally inappropriate for a release branch? Gr. Steven
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote: > On Wednesday 01 March 2006 21:14, H. J. Lu wrote: > > Is 4.1 branch open now? I'd like to back port the x86 > > -mtune=generic patch: > > Isn't that totally inappropriate for a release branch? > What is it inappropriate about? H.J.
Re: GCC 4.1.0 Released
On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote: > > On Wednesday 01 March 2006 21:14, H. J. Lu wrote: > > > Is 4.1 branch open now? I'd like to back port the x86 > > > -mtune=generic patch: > > > > Isn't that totally inappropriate for a release branch? > > > > What is it inappropriate about? It's a new feature and not a fix for a regression. -> totally inappropriate. Richard.
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 09:42:19PM +0100, Richard Guenther wrote: > On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote: > > > On Wednesday 01 March 2006 21:14, H. J. Lu wrote: > > > > Is 4.1 branch open now? I'd like to back port the x86 > > > > -mtune=generic patch: > > > > > > Isn't that totally inappropriate for a release branch? > > > > > > > What is it inappropriate about? > > It's a new feature and not a fix for a regression. -> totally inappropriate. It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. I can't recommond gcc 4.1 to most people using IA32/x86-64. This change is specific to the IA32/x86-64 backend and won't affect any other targets. H.J.
Re: GCC 4.1.0 Released
> > It's a new feature and not a fix for a regression. -> totally > > inappropriate. > > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc > 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. I > can't recommond gcc 4.1 to most people using IA32/x86-64. This change > is specific to the IA32/x86-64 backend and won't affect any other > targets. Presumably it's no worse than 4.0 though. Paul
Re: GCC 4.1.0 Released
On Wednesday 01 March 2006 21:49, H. J. Lu wrote: > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc > 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. Oh, really? Where are the numbers you have to support this, may I say, unlikely claim? It seemed to me that the patch you propose does not help that much at all. At least, if it does then that was not clear from the initial postings for the trunk, where except for Nocona it was a wash. > I can't recommond gcc 4.1 to most people using IA32/x86-64. You'd have to recommend ICC anyway :-P GCC 4.1 works a lot better for me on my AMD64 box than any previous GCC (except for the usual compile time regressions). so I _would_ recommend it to, well, everyone! > This change > is specific to the IA32/x86-64 backend and won't affect any other > targets. Hmm... I thought Mark's message was pretty clear: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00060.html To quote: "The GCC 4.1 branch is now open, under the usual branch rules: fixes for regressions only." Those are just the same rules that gcc has had for release branches since forever. I think everyone understands that you, with an Intel cap on, have to care more about Nocona than about GCC stability in general. But that doesn't mean that the rules that apply to everyone else should not apply to you. Your patch implements a new feature. New features usually don't fix regression. So your patch should be considered for GCC 4.1 IMHO. Gr. Steven
Re: Bootstrap failure on trunk: x86_64-linux-gnu
On Wed, 2006-03-01 at 08:24 -0500, Richard Kenner wrote: > So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface > issue, thanks for spotting this! > > Sorry, my last suggestion is clearly wrong. I think is right. > > *** uintp.adb 12 Sep 2003 21:50:56 - 1.80 > --- uintp.adb 1 Mar 2006 13:16:21 - > *** package body Uintp is > *** 591,595 > > begin > ! if UI_Is_In_Int_Range (Input) then >Num := abs (UI_To_Int (Input)); >Bits := 0; > --- 591,598 > > begin > ! if Input = Uint_Int_First then > ! return Int'Size; > ! > ! elsif UI_Is_In_Int_Range (Input) then >Num := abs (UI_To_Int (Input)); >Bits := 0; It certainly fixes the testsuite hang. If it's the correct fix, then can you please make sure it gets installed. Thanks, Jeff
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote: > On Wednesday 01 March 2006 21:49, H. J. Lu wrote: > > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc > > 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. > > Oh, really? Where are the numbers you have to support this, may I > say, unlikely claim? Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 using "-O2 -ffast-math" on Nocona: 164.gzip2.50% 175.vpr 1.55% 176.gcc -0.33% 181.mcf 0.85% 186.crafty 0.06% 197.parser 0.62% 252.eon 8.58% 253.perlbmk 2.75% 254.gap 0.66% 255.vortex 7.59% 256.bzip2 4.45% 300.twolf 21.11% SPECint_base20004.04% 168.wupwise 39.10% 171.swim38.88% 172.mgrid 61.64% 173.applu 37.62% 177.mesa3.12% 178.galgel 27.13% 179.art 18.98% 183.equake 26.67% 187.facerec 0.35% 188.ammp36.78% 189.lucas 3.52% 191.fma3d 42.71% 200.sixtrack116.13% 301.apsi32.75% SPECfp_base2000 32.18% > > This change > > is specific to the IA32/x86-64 backend and won't affect any other > > targets. > > Hmm... I thought Mark's message was pretty clear: > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00060.html > To quote: > "The GCC 4.1 branch is now open, under the usual branch rules: fixes for > regressions only." > The exception is the rule. We have done so on gcc 3.4 branch: http://gcc.gnu.org/ml/gcc-cvs/2004-04/msg00775.html H.J.
Re: GCC 4.1.0 Released
On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote: > > On Wednesday 01 March 2006 21:49, H. J. Lu wrote: > > > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc > > > 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. > > > > Oh, really? Where are the numbers you have to support this, may I > > say, unlikely claim? > > Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 > using "-O2 -ffast-math" on Nocona: Please post more meaningful numbers, like a comparison to -mtune=nocona, not whatever you used (the old default is i386 or i586). Richard.
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 10:43:40PM +0100, Richard Guenther wrote: > On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote: > > > On Wednesday 01 March 2006 21:49, H. J. Lu wrote: > > > > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc > > > > 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. > > > > > > Oh, really? Where are the numbers you have to support this, may I > > > say, unlikely claim? > > > > Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 > > using "-O2 -ffast-math" on Nocona: > > Please post more meaningful numbers, like a comparison to -mtune=nocona, > not whatever you used (the old default is i386 or i586). That is the whole point: I'd like to back port the -mtune=generic change to 4.1 branch. There are so many different IA32/x86-64 processors. The default optimization is more useful than -mtune=xxx. The new default (-mtune=generic) is much better than the old one for the current IA32/x86-64 processors. H.J.
Re: GCC 4.1.0 Released
> That is the whole point: I'd like to back port the -mtune=generic > change to 4.1 branch. There are so many different IA32/x86-64 > processors. The default optimization is more useful than -mtune=xxx. > The new default (-mtune=generic) is much better than the old one for > the current IA32/x86-64 processors. You are missing the whole point about a release branch though. Yes there have been exceptions in the past to the policy but they should not be taken for granted. GCC is growing up as a real professional compiler which means no new features in minor revisions aka bug fixes releases. Yes there are a few exception but others and I feel this is not an example of one of the exception at least at this point in time. One of the reasons why people are against this patch is because one it touches the most popular target which means it could unstablize it. Two there are still known regressions with this patch. PR 26146 for an example. Thanks, Andrew Pinski
Re: GCC 4.1.0 Released
H. J. Lu wrote: > Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 > using "-O2 -ffast-math" on Nocona: Steven's right; this is clearly a new feature. HJ's also right; we've made exceptions before. Like Steven, I would like to see what the difference is between -mtune=generic and -mtune=nocona. If there is not much difference, then that's an argument against a backport; just tell users to add -mtune=nocona. It's up to architecture maintainers to get defaults set well for their systems in advance of releases. I'd also like to hear from our IA32 maintainers. I'm going to set the bar here relatively high on several grounds: 1. I've just been reminded, once again, of the dangers of "safe" patches; c.f., the Alpha OSF threads patch for 4.1.0 which turned out to break NetBSD. (Fortunately, that configuration was badly enough broken before the patch that I don't think any terribly serious damage was done; 4.1.1 will presumably have Roger's patches which fix all of that.) I'm in no way criticizing Roger, and it was I who approved the patch; however, the key point is that danger lurks everywhere. 2. IA32 is one of, if not the, most popular GCC architectures. On the one hand, yes, that argues for making it perform well there; on the other, it also argues very strongly for stability. Effectively changing the default optimization behavior on a release branch substantially invalidates previous validation done on that branch. 3. Slippery slope. Every time I bend the rules, I get criticized for bending the rules, and I get besieged by people who want other rules bent, and then I get criticized for bending rule X for person A, but not rule Y for person B. I've got a thick skin, and I feel omfortable exercising my own non-algorithmic discretion to do what I believe is the right thing. But, I will also be sensitive to the developer community's desire for predictability of decision-making. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.0 Released
Joe Buck wrote: > What is the basis for the report that older tars don't work? This posting: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01861.html It may certainly be the case that some patched version of tar on RHEL works fine (one would indeed hope and expect that distributors are adding value in precisely such ways!) but it's better to be safe than sorry, and I didn't have the resources to verify exactly which versions might or might not work. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Bootstrap failure on trunk: x86_64-linux-gnu
Here's the next segment in the ongoing saga of VRP vs Ada...
Not surprisingly we have another case where an object gets a
value outside of its TYPE_MIN_VALUE/TYPE_MAX_VALUE defined range.
Investigating the c460008 testsuite failure we have the following
code for Fixed_To_Short before VRP runs:
# BLOCK 4
# PRED: 3 (fallthru,exec)
D.1294_13 = D.1294_12;
D.1309_32 = for_the_value_31 /[rd] 10;
D.1310_33 = (UNSIGNED_64) D.1309_32;
if (D.1310_33 > 255) goto ; else goto ;
# SUCC: 5 (true,exec) 6 (false,exec)
# BLOCK 5
# PRED: 4 (true,exec)
:;
__gnat_rcheck_10 ("c460008.adb", 162);
# SUCC: 13 (ab,eh,exec) 18 (ab,eh,exec) 29 (ab,eh,exec)
# BLOCK 6
# PRED: 4 (false,exec)
:;
iftmp.78_63 = D.1309_32;
iftmp.78_64 = D.1309_32;
D.1316_65 = (c460008__unsigned_edge_8) D.1309_32;
if (D.1316_65 == 255) goto ; else goto ;
# SUCC: 7 (true,exec) 8 (false,exec)
D.1309_32's type has the range [0x8000,0x7fff]
with 64bit precision.
In block #6 we cast the value of D.1309_32 into a smaller type,
specifically c460008__unsigned_edge_8 and store the result into
D.1316_64 which has type c460008__unsigned_edge_8.
c460008__unsigned_edge_8's range is [ ,254] with 8 bit precision.
Note carefully that with the range [ ,254] (according to
TYPE_MIN_VALUE/TYPE_MAX_VALUE) that the test
if (D.1316_65 == 255)
Must always be false. So VRP, as expected, wipes out test
completely.
The problem (of course) is D.1316_65 can and does actually hold
values outside the range [ ,254] at runtime. For example, it could
hold the value 255 if D.1309_32 had the value 255, which would occur
if for_the_value_31 held the value 2550.
Someone with a better knowledge of Ada is going to need to step
in here, but based on the type information provided by the Ada
front-end, VRP is doing the right thing here.
Jeff
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 02:24:58PM -0800, Mark Mitchell wrote: > Joe Buck wrote: > > > What is the basis for the report that older tars don't work? > > This posting: > > http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01861.html > > It may certainly be the case that some patched version of tar on RHEL > works fine (one would indeed hope and expect that distributors are > adding value in precisely such ways!) but it's better to be safe than > sorry, and I didn't have the resources to verify exactly which versions > might or might not work. I just repeated the test with the FSF 1.13 release. Again, no complaints and diff -r matches what 1.15.1 gives. I suppose I could repeat the test with the gcc 4.1 RC1 tarball, where David E. saw a problem.
Re: GCC 4.1.0 Released
On Wednesday 01 March 2006 22:06, Steven Bosscher wrote: > Your patch implements a new feature. New features usually don't fix > regression. So your patch should be considered for GCC 4.1 IMHO. I mean should not, obviously. Gr. Steven
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 02:19:47PM -0800, Mark Mitchell wrote: > H. J. Lu wrote: > > > Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 > > using "-O2 -ffast-math" on Nocona: > > Steven's right; this is clearly a new feature. HJ's also right; we've > made exceptions before. > > Like Steven, I would like to see what the difference is between > -mtune=generic and -mtune=nocona. If there is not much difference, then Here are diffs of "-O2 -mtune=nocona -ffast-math" vs "-O2 -mtune=generic -ffast-math" on Nocona: 164.gzip1.30% 175.vpr -0.29% 176.gcc -4.04% 181.mcf 0.74% 186.crafty 1.65% 197.parser -0.10% 252.eon -0.38% 253.perlbmk 5.25% 254.gap 0.93% 255.vortex 1.54% 256.bzip2 0.72% 300.twolf 9.70% SPECint_base20001.31% 168.wupwise 2.49% 171.swim-0.55% 172.mgrid 6.46% 173.applu 0.65% 177.mesa2.56% 178.galgel 0.14% 179.art 1.79% 183.equake 0.79% 187.facerec -0.07% 188.ammp4.86% 189.lucas 1.21% 191.fma3d 1.08% 200.sixtrack0.00% 301.apsi1.21% SPECfp_base2000 1.62% I'd like to see the default -O2 generate decent code for Nocona. It is independent of improviong -mtune=nocona for Nocona. > that's an argument against a backport; just tell users to add > -mtune=nocona. It's up to architecture maintainers to get defaults set > well for their systems in advance of releases. > > I'd also like to hear from our IA32 maintainers. My IA32 numbers show that -mtune=generic gives the better SPEC CPU 2K -O2 numbers on Dothan, Yonah, Northwood and Yonah than the previous -O2 option. > > 2. IA32 is one of, if not the, most popular GCC architectures. On the > one hand, yes, that argues for making it perform well there; on the > other, it also argues very strongly for stability. Effectively changing > the default optimization behavior on a release branch substantially > invalidates previous validation done on that branch. > The last thing I want to see is the instability on IA32. I can't guarantee it won't happen. But I will do my best to fix it if the backported patch is the cause. H.J.
Re: GCC 4.1.0 Released
On Wednesday 01 March 2006 23:51, H. J. Lu wrote: > I'd like to see the default -O2 generate decent code for Nocona. But then, you did so too months ago, when the GCC 4.1 development cycle was still in stage1/stage2. Nocona has been around for a very long time already (I have a Prescott-T myself which is going to celebrate its second birthday soon), so you've had plenty of time to make -O2 produce decent code for Nocona, really. You just didn't do that. What's that what my professor always said... Ah yes, "Poor planning by you does not constitute an emergency for me". > The last thing I want to see is the instability on IA32. I can't > guarantee it won't happen. But I will do my best to fix it if the > backported patch is the cause. You still have to fix a few open regressions against 4.2 caused by this patch, and 4.2 has not even received as much testing as 4.1 so it is almost certain that there are going to be more bugs that your patch causes or will expose. Gr. Steven
Re: GCC 4.1.0 Released
H. J. Lu wrote: > Here are diffs of "-O2 -mtune=nocona -ffast-math" vs > "-O2 -mtune=generic -ffast-math" on Nocona: A 1.5% performance improvement, while certainly significant for some users, is not worth taking any serious risks on a release branch. The purpose of bug-fix releases on the release branch is to correct regressions. The goal is that (a) any happy user of 4.1.0 can upgrade to 4.1.1, and (b) that users presently stuck with older releases because of regressions in 4.1.0 can upgrade to 4.1.1. In other words, the goal is to shift the userbase forward to 4.1.x -- not to improve the experience of people already using 4.1.0. > My IA32 numbers show that -mtune=generic gives the better SPEC CPU 2K > -O2 numbers on Dothan, Yonah, Northwood and Yonah than the previous > -O2 option. Yes, I understand. I hope that 4.2 will in fact have quite a few improvements on quite a few architectures of at least this magnitude! However, we're not going to backport them all to 4.1. > The last thing I want to see is the instability on IA32. I can't > guarantee it won't happen. But I will do my best to fix it if the > backported patch is the cause. The first step is to address regressions on the mainline. I have not myself verified the claim, but there has been a suggestion that there is at least one open regression due to the patch. If there are any known regressions from the patch, it's certainly not eligible for a backport. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)
Ok this test is checking a corner case of the language, namely
non power of two modular types.
It looks like this one needs overflow checking to pass (-gnato):
$ gnatmake -f -I../../../support/ c460008.adb
gcc -c -I../../../support/ c460008.adb
gcc -c -I./ -I../../../support/ -I-
/home/guerby/work/gcc/build/build-head-20060301T130355/gcc/testsuite/ada/acats/support/report.adb
gnatbind -aO./ -I../../../support/ -I- -x c460008.ali
gnatlink c460008.ali
$ ./c460008
,.,. C460008 ACATS 2.5 06-03-02 00:28:43
C460008 Check that conversion to a modular type raises
Constraint_Error when the operand value is outside the
base range of the modular type.
* C460008 Fix expected Constraint_Error D2S Dynamic, Negative.
- C460008 Value of 251 not properly converted.
* C460008 Fix expected Constraint_Error D2S Static, Over_Mod.
- C460008 Value of 204 not properly converted.
* C460008 Fix expected Constraint_Error D28 Static, Negative.
- C460008 Value of 255 not properly converted.
* C460008 Fix expected Constraint_Error D28 Static, At_Mod.
- C460008 Value of 0 not properly converted.
* C460008 Fix expected Constraint_Error D28 Dynamic, Over_Mod.
- C460008 Value of 209 not properly converted.
C460008 FAILED .
$ gnatmake -f -gnato -I../../../support/ c460008.adb
gcc -c -gnato -I../../../support/ c460008.adb
gcc -c -I./ -gnato -I../../../support/ -I-
/home/guerby/work/gcc/build/build-head-20060301T130355/gcc/testsuite/ada/acats/support/report.adb
gnatbind -aO./ -I../../../support/ -I- -x c460008.ali
gnatlink c460008.ali
$ ./c460008
,.,. C460008 ACATS 2.5 06-03-02 00:27:21
C460008 Check that conversion to a modular type raises
Constraint_Error when the operand value is outside the
base range of the modular type.
C460008 PASSED .
I'm rerunning the whole testsuite on x86_64-linux with an edited
gcc/testsuite/ada/acats/run_all.sh that includes -gnato for all tests:
gnatflags="-gnatws -gnato"
We'll see what new ACATS FAIL go away.
Richard, Arnaud, could you check amongst GNAT experts if for such types
(non power of two modulus), it's not worth enabling overflow checks by
default now that we have VRP doing non trivial optimisations? People
using non power of two modulus are not caring for performance anyway, so
having a compliant implementation by default won't harm.
Laurent
On Wed, 2006-03-01 at 15:35 -0700, Jeffrey A Law wrote:
> Here's the next segment in the ongoing saga of VRP vs Ada...
> Not surprisingly we have another case where an object gets a
> value outside of its TYPE_MIN_VALUE/TYPE_MAX_VALUE defined range.
>
> Investigating the c460008 testsuite failure we have the following
> code for Fixed_To_Short before VRP runs:
>
>
>
>
> # BLOCK 4
> # PRED: 3 (fallthru,exec)
> D.1294_13 = D.1294_12;
> D.1309_32 = for_the_value_31 /[rd] 10;
> D.1310_33 = (UNSIGNED_64) D.1309_32;
> if (D.1310_33 > 255) goto ; else goto ;
> # SUCC: 5 (true,exec) 6 (false,exec)
>
> # BLOCK 5
> # PRED: 4 (true,exec)
> :;
> __gnat_rcheck_10 ("c460008.adb", 162);
> # SUCC: 13 (ab,eh,exec) 18 (ab,eh,exec) 29 (ab,eh,exec)
>
> # BLOCK 6
> # PRED: 4 (false,exec)
> :;
> iftmp.78_63 = D.1309_32;
> iftmp.78_64 = D.1309_32;
> D.1316_65 = (c460008__unsigned_edge_8) D.1309_32;
> if (D.1316_65 == 255) goto ; else goto ;
> # SUCC: 7 (true,exec) 8 (false,exec)
>
> D.1309_32's type has the range [0x8000,0x7fff]
> with 64bit precision.
>
> In block #6 we cast the value of D.1309_32 into a smaller type,
> specifically c460008__unsigned_edge_8 and store the result into
> D.1316_64 which has type c460008__unsigned_edge_8.
>
> c460008__unsigned_edge_8's range is [ ,254] with 8 bit precision.
>
> Note carefully that with the range [ ,254] (according to
> TYPE_MIN_VALUE/TYPE_MAX_VALUE) that the test
>
> if (D.1316_65 == 255)
>
> Must always be false. So VRP, as expected, wipes out test
> completely.
>
> The problem (of course) is D.1316_65 can and does actually hold
> values outside the range [ ,254] at runtime. For example, it could
> hold the value 255 if D.1309_32 had the value 255, which would occur
> if for_the_value_31 held the value 2550.
>
> Someone with a better knowledge of Ada is going to need to step
> in here, but based on the type information provided by the Ada
> front-end, VRP is doing the right thing here.
>
>
> Jeff
>
>
Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)
It looks like this one needs overflow checking to pass (-gnato): ACATS should aways be run with -gnato since that's the only way to get the behavior mandated by RM. Why are we running it without it? Is this new? Certainly -gnato was used during validations. Richard, Arnaud, could you check amongst GNAT experts if for such types (non power of two modulus), it's not worth enabling overflow checks by default now that we have VRP doing non trivial optimisations? People using non power of two modulus are not caring for performance anyway, so having a compliant implementation by default won't harm. Hardly worth writing the code to bother with that given how rare such things are ...
Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)
On Wed, 2006-03-01 at 18:48 -0500, Richard Kenner wrote: > It looks like this one needs overflow checking to pass (-gnato): > > ACATS should aways be run with -gnato since that's the only way to > get the behavior mandated by RM. Why are we running it without it? Is > this new? Certainly -gnato was used during validations. On GCC we use -gnato on tests known to need it (/gcc/testsuite/ada/acats/overflow.lst) since we want to test flags the typical GCC/Ada user does use and not what official validation requires (which is -gnato -gnatE IIRC). VRP might now force us to update the overflow list but I'm not sure about switching to a full -gnato everywhere. > Richard, Arnaud, could you check amongst GNAT experts if for such > types (non power of two modulus), it's not worth enabling overflow > checks by default now that we have VRP doing non trivial > optimisations? People using non power of two modulus are not caring > for performance anyway, so having a compliant implementation by > default won't harm. > > Hardly worth writing the code to bother with that given how rare > such things are ... True. Laurent
Re: ACATS c460008 and VRP
Laurent GUERBY wrote: Ok this test is checking a corner case of the language, namely non power of two modular types. It looks like this one needs overflow checking to pass (-gnato): All ACATS tests should be run with -gnatE -gnato
Re: problem with the gcc 3.4.4
On Mar 1, 2006, at 3:47 AM, HASSAN AL MOATASSIME wrote: I have a problem with the compiler gcc 3.4.4. With the gcc 3.2 compiler, i have no problem with the following instruction : creal(U0[i])=PartieReelle; cimag(U0[i])=PartieImaginaire; Now with the gcc 3.4.4 i have the folowing message : -- erreur: invalid lvalue in assignment Wrong mailing list, please use gcc-help. I suspect that your code is invalid C/C++ code and that you may want to read up on what language you're using and then change your code to conform to that language.
Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)
On GCC we use -gnato on tests known to need it (/gcc/testsuite/ada/acats/overflow.lst) since we want to test flags the typical GCC/Ada user does use and not what official validation requires (which is -gnato -gnatE IIRC). Well that would make the most sense if the code in the ACATS tests was typical of what users *write* but, as we both know, it's mostly boundary cases in the language ...
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote: > H. J. Lu wrote: > > > Here are diffs of "-O2 -mtune=nocona -ffast-math" vs > > "-O2 -mtune=generic -ffast-math" on Nocona: > > A 1.5% performance improvement, while certainly significant for some > users, is not worth taking any serious risks on a release branch. The You are comparing apply with orange. If a user uses -O2, he/she will see much more than that. > > The first step is to address regressions on the mainline. I have not > myself verified the claim, but there has been a suggestion that there is > at least one open regression due to the patch. If there are any known > regressions from the patch, it's certainly not eligible for a backport. I am only aware of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26146 and I have a patch. BTW, I don't think it is a real regression, just a latent bug. I doubt # configure i[456]86-pc-solaris2.10 # onfigure --with-cpu=i[3456]86 i386-pc-solaris2.10 had ever worked. In any case, please CC me any -mtune=generic patch. H.J.
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 04:05:16PM -0800, H. J. Lu wrote: > On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote: > > H. J. Lu wrote: > > > > > Here are diffs of "-O2 -mtune=nocona -ffast-math" vs > > > "-O2 -mtune=generic -ffast-math" on Nocona: > > > > A 1.5% performance improvement, while certainly significant for some > > users, is not worth taking any serious risks on a release branch. The > > You are comparing apply with orange. If a user uses -O2, he/she will > see much more than that. I meant to say "comparing apple with orange". > > > > > The first step is to address regressions on the mainline. I have not > > myself verified the claim, but there has been a suggestion that there is > > at least one open regression due to the patch. If there are any known > > regressions from the patch, it's certainly not eligible for a backport. > > I am only aware of > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26146 > > and I have a patch. BTW, I don't think it is a real regression, just > a latent bug. I doubt > > # configure i[456]86-pc-solaris2.10 > # onfigure --with-cpu=i[3456]86 i386-pc-solaris2.10 > > had ever worked. > > In any case, please CC me any -mtune=generic patch. Let me rephrase, please CC me any -mtune=generic related bugs. H.J.
Re: iWMMXt/Linux EABI toolchain
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 06:20:53PM +, Steven Newbury wrote: > > OK, thank-you. I'll target "arm-iwmmxt-linux-gnueabi" with --with-cpu= etc > and > > --disable-multilib. The vendor string is for my build scripts and also > will > > help differentiate the toolchain, is that valid? > > Yep. I've given this a go. I've successully built a stage1 cross compiler and installed the glibc headers. However, on re-building gcc it fails to link libgcc: ... ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so /usr/arm-iwmmxt-linux-gnueabi/bin/ld: crti.o: No such file: No such file or directory collect2: ld returned 1 exit status make[3]: *** [libgcc_s.so] Error 1 Any hints? Steve ___ Win a BlackBerry device from O2 with Yahoo!. Enter now. http://www.yahoo.co.uk/blackberry
Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)
> Richard, Arnaud, could you check amongst GNAT experts if for such types > (non power of two modulus), it's not worth enabling overflow checks by > default now that we have VRP doing non trivial optimisations? People > using non power of two modulus are not caring for performance anyway, so > having a compliant implementation by default won't harm. Changing compilation options to paper over potential bugs is IMHO not the best approach, especially if the new options are little used. And the current implementation of -gnato makes it a "heavy" option, not a "light" one. -- Eric Botcazou
Re: ACATS c460008 and VRP
Laurent GUERBY wrote: VRP might now force us to update the overflow list but I'm not sure about switching to a full -gnato everywhere. well you can expect some fiddling each version if you work this way
Re: ACATS c460008 and VRP
Eric Botcazou wrote: Richard, Arnaud, could you check amongst GNAT experts if for such types (non power of two modulus), it's not worth enabling overflow checks by default now that we have VRP doing non trivial optimisations? People using non power of two modulus are not caring for performance anyway, so having a compliant implementation by default won't harm. Changing compilation options to paper over potential bugs is IMHO not the best approach, especially if the new options are little used. And the current implementation of -gnato makes it a "heavy" option, not a "light" one. it's not a bug, -gnato is clearly documented as required in this case, what makes you think otherwise? Non power of 2 modular is so rare that using -gnato in this case seems just fine to me.
Re: GCC 4.1.0 Released
H. J. Lu wrote: > You are comparing apply with orange. If a user uses -O2, he/she will > see much more than that. We can argue about that, but I don't think so. I'm comparing a user can achieve without the patch with the performance they can achieve with the patch. On all chips, for all time, users have been expected to specify their target CPU in order to get good performance. It's swell that GCC 4.2 will work better by default on IA32, but that's not a compelling argument for a backport. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: iWMMXt/Linux EABI toolchain
On Thu, Mar 02, 2006 at 12:27:46AM +, Steven Newbury wrote: > I've given this a go. I've successully built a stage1 cross compiler and > installed the glibc headers. However, on re-building gcc it fails to link > libgcc: > > ... ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp > ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so > /usr/arm-iwmmxt-linux-gnueabi/bin/ld: crti.o: No such file: No such file or > directory > collect2: ld returned 1 exit status > make[3]: *** [libgcc_s.so] Error 1 > > Any hints? Please either take this to the crossgcc list or look at how crosstool works. This is a FAQ for building Linux cross-compilers. -- Daniel Jacobowitz CodeSourcery
Re: Marking a builtin function as `noreturn'.
Daniel Towner <[EMAIL PROTECTED]> writes: > I maintain a port of gcc for an embedded processor which has a HALT > instruction. This instruction stops the processor, and generates an > appropriate interrupt to indicate to its parent system that it has > stopped. The instruction is accessed by the programmer using a > port-specific builtin, which can then be used, amongst other things, > to implement the `assert' macro. > > At the moment, whenever a HALT instruction is emitted, the compiler > still seems to assume that execution will continue after the HALT > instruction has executed (e.g., the compiler emits branches to the > function epilogue, etc.). I would like the compiler to treat the > builtin instruction as though it had the attribute `noreturn'. I have > added this attribute to the builtin declaration in the > TARGET_INIT_BUILTINS function, but it appears to make no difference. I > may have got the code wrong, but assuming the code is correct, should > gcc allow a builtin to be marked as a noreturn? Should a builtin > marked in this way stop any code flow after the HALT? Is there another > way to achieve the effect I am after? Define the builtin function to first emit the HALT instruction and then call emit_barrier(). Ian
Re: GCC 4.1.0 Released
On 03/01/06 17:51, H. J. Lu wrote: > SPECint_base2000 1.31% > SPECfp_base2000 1.62% > All these numbers are within the usual SPEC noise. Not Worth It.
Re: GCC-4.1.x include/ssl/*.h ??
Greg Schafer wrote: > Remove the -j3 and all is well. I suppose most folks never run `make > install' in parallel.. but sometimes it's convenient to just simply: > > export MAKEFLAGS=-j3 > > for big compile jobs. I'm not aware of anything parallel-make unfriendly about my patch, but I can believe there's a problem in there somewhere. I never run "make install" in parallel because, frankly, it's *never* worked for me; I just thought all of our makefiles were generally broken for parallel installation. :-( -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.0 Released
> Dan Kegel writes: >> The problem has nothing to do with warnings from tar, which are neither >> errors nor silent failures. I believe a file either got skipped or >> unpacked with the wrong name. Dan> Egads. Can you point me to more info? I've been building with older Dan> versions of tar without any problem beyond the warnings. The problem I experienced was a missing last character of some very long filenames when untarring. Some C++ header files with .hpp prefix were untarred as .hp. Listing the files in the tarball displayed the same filename truncation. Upgrading GNU tar to 1.15.1 fixed the problem for me. David
Re: GCC 4.1.0 Released
David Edelsohn <[EMAIL PROTECTED]> writes: > Upgrading GNU tar to 1.15.1 fixed the problem for me. So what is the actual requirement - 1.14 or "1.14 or above" ? -- With regards, Roman.
