RE: How to enable Mudflap in gcc 4.x?
Frank Ch. Eigler [EMAIL PROTECTED] wrote: libmudflap needs to know the know the name of the entry point symbol, to enable one of its heuristics. See the ENTRY_POINT area in configure.ac, and update it for your own runtime. Be aware that libmduflap's libc-wrapper functions may need porting for your libc. Thanks for the reply. When I try to build the libmudflap library separately for (Renesas)sh-elf target after building the complete toolchain, it automatically gets configured for i386-redhat-linux target. Is it the case that libmudflap only supports i386 target and not others? Do I need to port it for sh-elf target? Regards, Deepen Mantri KPIT Cummins InfoSystems Ltd. Pune, India ~ Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C and M32C Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on February 6, 07 ~~
Re: How to enable Mudflap in gcc 4.x?
On Jun 4, 2007, at 12:09 AM, Deepen Mantri wrote: Frank Ch. Eigler [EMAIL PROTECTED] wrote: libmudflap needs to know the know the name of the entry point symbol, to enable one of its heuristics. See the ENTRY_POINT area in configure.ac, and update it for your own runtime. Be aware that libmduflap's libc-wrapper functions may need porting for your libc. Thanks for the reply. When I try to build the libmudflap library separately for (Renesas)sh-elf target after building the complete toolchain, it automatically gets configured for i386-redhat-linux target. Is it the case that libmudflap only supports i386 target and not others? Do I need to port it for sh-elf target? Perhaps, but you want to build it as part of your target libraries using --enable-libmudflap. When you build it after you're not using host and target and therefore it's being built for your machine (i386- redhat-linux). -eric
question about switch table
Hi, Now, i wanna generate a switch table just like ARM tbb instruction. The switch table should be located at .rdata section, so I should use .L3-.L8_1, but not .L3-.L8. How could i implement this? Any target macro can do it? Please look at the following code fragment. (.L3-.L8_1)/2 is what i want, but not .L3-.L8. la r7, $L8 tbb [r7, r6] .L8_1 .rdata .L8: .byte (.L3-.L8)/2 .byte (.L4-.L8)/2 .byte (.L5-.L8)/2 .byte (.L6-.L8)/2 .byte (.L7-.L8)/2 .text Best regards Ligang
Re: How to enable Mudflap in gcc 4.x?
Thanks for the reply. I did remove --enable-libmudflap option from the build script and followed following steps for libmudflap configuration: Why on earth would you do this? I created a separate build folder and from there a) [libmudflap source path]/configure --target=sh-elf --prefix=[My prefix folder path] b) make c) make install By this, libmudflap.a got created but for i386-redhat-linux target. No, at the toplevel (just like your normal build of the compiler and target libraries): configure --enable-languages=c --disable-multilib --enable-libmudflap --target=sh-elf ; make -j8 all-gcc all-target and you'll get this: configure: error: none of the known symbol names works make: *** [configure-target-libmudflap] Error 1 which means that libmudflap needs to be ported to sh-elf. -eric
Re: [OT] Re: Git repository with full GCC history
On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote: If I can reproduce it I'll see if I can find some webspace. If you mail me a SSH public key you can also put it on git.infradead.org. -- dwmw2
Re: [OT] Re: Git repository with full GCC history
David Woodhouse wrote: On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote: If I can reproduce it I'll see if I can find some webspace. If you mail me a SSH public key you can also put it on git.infradead.org. Come visit git.infradead.org and its GCC development fork. -- // Bernardo Innocenti \X/ http://www.codewiz.org/
Re: Help in understanding ccp propagator
I will greatly appreciate any suggestions regarding the following problem I have with the ccp propagator. I am testing the new store ccp patch which propagates constants by walking the virtual use-def chain (http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00055.html) and I encountered the following problem while testing tree_join.cc file which is under libstdc++-v3 testsuite: BTW, a lot of these will be caught with the new VN i posted, whicih should be reviewed and go in soon. Thanks, should it handle cases like the one in the following example - http://gcc.gnu.org/ml/gcc-patches/2007-03/txt00081.txt? I tried it with the VN patch but it seems to not caught it... The final propagator replaces the right operand (D.65705_98) in the following if condition with a constant zero which causes the program to be aborted as i0_62 is not always zero: # i0_62 = PHI i0_5(29), 0(3) L139:; D.61410.first = i0_62; ... D.65705_98 = D.61410.first; - if (D.65704_96 = 0) + if (D.65704_96 = D.65705_98) goto bb 11; else goto bb 14; Tracing the execution of the propagator it seems that the if statement is first been propogated with zero after simulating the execution; but not updated after the lattice value of the variables it depends on changed. Does your store CPP properly say the vdefs have changed when a statement's lattice value changes? I am not sure I understand. The new patch uses the infrastructure of the propagator and I do not see an indication in the dumps for vdefs update after the lattice value is changed: 19930 19931 Visiting statement: 19932 D.61410.first = i0_62; 19933 19934 Lattice value changed to CONSTANT 0. Adding SSA edges to worklist. 19935 Thanks again fo your help, Revital
RE: How to enable Mudflap in gcc 4.x?
Eric Christopher wrote: No, at the toplevel (just like your normal build of the compiler and target libraries): configure --enable-languages=c --disable-multilib --enable-libmudflap --target=sh-elf ; make -j8 all-gcc all-target and you'll get this: configure: error: none of the known symbol names works make: *** [configure-target-libmudflap] Error 1 which means that libmudflap needs to be ported to sh-elf. How should I start the porting? Do you have any document related to such porting? I would really appreciate your help if you could guide me in this.
Re: How to enable Mudflap in gcc 4.x?
Hi - which means that libmudflap needs to be ported to sh-elf. How should I start the porting? Do you have any document related to such porting? [...] First thing is to get past that autoconf error. Check your linker script for the default entry point symbol's name, and give it to libmudflap/configure.ac (then regenerate configure). Next, overcome build problems (if any) to the extent that a libmudflap.a gets compiled. Then, start running the test suite. It does not cover all the libc function wrappers, so at this point you might as well start compiling your own smaller code with -fmudflap and see what happens. It may be reassuring that it is not sh-elf per se that needs porting, but rather your runtime C library. There is little to no architecture-specific code in there. - FChE
current gcc trunk testsuite failure on cygwin: Assembler messages: Warning: end of file in string; '' inserted: Warning: .stabs: missing comma
phew, a few of the cygwin failures show up like this: Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o 20001226-1.o /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c (timeout = 300) spawn /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o 20001226-1.o /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s: Assembler messages: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs: missing comma output is: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s: Assembler messages: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs: missing comma FAIL: gcc.c-torture/compile/20001226-1.c (test for excess errors) Excess errors: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs: missing comma and Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o limits-declparen.o /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-declparen.c (timeout = 300) spawn /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o limits-declparen.o /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-declparen.c /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s: Assembler messages: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:18: Warning: .stabs: missing comma output is: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s: Assembler messages: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:18: Warning: .stabs: missing comma FAIL: gcc.c-torture/compile/limits-declparen.c (test for excess errors) Excess errors: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:18: Warning: .stabs: missing comma and Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o limits-exprparen.o /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-exprparen.c (timeout = 300) spawn /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o limits-exprparen.o /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-exprparen.c /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s: Assembler messages: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:18: Warning: .stabs: missing comma output is: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s: Assembler messages: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:18: Warning: .stabs: missing comma FAIL: gcc.c-torture/compile/limits-exprparen.c (test for excess errors) Excess errors: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:18: Warning: .stabs: missing comma and Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o limits-pointer.o /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-pointer.c (timeout = 300) spawn /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o limits-pointer.o /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-pointer.c /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s: Assembler messages: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:18: Warning: .stabs: missing comma output is: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s: Assembler messages: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:18: Warning: .stabs: missing comma FAIL: gcc.c-torture/compile/limits-pointer.c (test for excess errors) Excess errors: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:18: Warning: .stabs: missing comma
Re: [OT] Re: Git repository with full GCC history
On Mon, 2007-06-04 05:17:17 -0400, Bernardo Innocenti [EMAIL PROTECTED] wrote: David Woodhouse wrote: On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote: If I can reproduce it I'll see if I can find some webspace. If you mail me a SSH public key you can also put it on git.infradead.org. Come visit git.infradead.org and its GCC development fork. *cough* No reason to fork. At least I'm just too used to GIT these days and like it quite a lot, that's why I work on getting the toolchain repos converted (and kept up-to-date!) somewhere as GIT repos. This just eases the pain keeping those patches up-to-date in some branches, that aren't yet ready for merging. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of: http://perl.plover.com/Questions.html the second : signature.asc Description: Digital signature
Re: What is purpose of numbered variables??
On 6/1/07 3:45 PM, Seema S. Ravandale wrote: int b; //local variable array[b] = c will be translated to b.0 = b; array[b.0] = c anything to do with SSA? Is 'b' an addressable variable or is it a regular local stack variable? If the latter, then this is a buglet in the conversion to GIMPLE form. We should probably check whether the array index is already a gimple register before creating b.0. It's not a big issue, though. Copy propagation should get rid of that very early on, but I agree that it would be worth fixing.
Re: Help in understanding ccp propagator
On 6/4/07, Revital1 Eres [EMAIL PROTECTED] wrote: I will greatly appreciate any suggestions regarding the following problem I have with the ccp propagator. I am testing the new store ccp patch which propagates constants by walking the virtual use-def chain (http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00055.html) and I encountered the following problem while testing tree_join.cc file which is under libstdc++-v3 testsuite: BTW, a lot of these will be caught with the new VN i posted, whicih should be reviewed and go in soon. Thanks, should it handle cases like the one in the following example - http://gcc.gnu.org/ml/gcc-patches/2007-03/txt00081.txt? I tried it with the VN patch but it seems to not caught it... I can modify it to catch it pretty easily, just walk back a few vuses if the current set of vuses is defined by something that does not actually touch our offset. s? I am not sure I understand. The new patch uses the infrastructure of the propagator and I do not see an indication in the dumps for vdefs update after the lattice value is changed: 19930 19931 Visiting statement: 19932 D.61410.first = i0_62; 19933 19934 Lattice value changed to CONSTANT 0. Adding SSA edges to worklist. 19935 Thanks again fo your help, Revital So uh, how do you expect the propagator to notice when the used variables have changed if the things the vdefs produced by D.61410.first are not marked as change (so that the immediate uses of it get processed). You will need to add this if it is not there already. Normally, the propagator says oh, the lattice value of D_64 changed, let me mark all it's immediate uses for reprocessing. The only thing that links memory defs to memory uses is the vdef/vuses, so you will have to be able to process and mark those
testsuite trigraphs.c failure due to cygwin stdio.h
-Original Message- From: Timothy C Prince [EMAIL PROTECTED] To: gcc@gcc.gnu.org Date: Mon, 04 Jun 2007 16:20:34 + In the message http://gcc.gnu.org/ml/gcc/2007-03/msg01088.html Dave Korn wrote: So, am I correct to believe that we need to use plain 'inline' for c99 after gcc 4.4, and 'extern inline' before that? That is, I think I need to write a test that looks like... #if ((__GNUC__ 4) || ((__GNUC__ == 4) (__GNUC_MINOR__ = 4))) \ defined (__STRICT_ANSI__) (__STRICT_ANSI__ != 0) \ defined (__STDC_VERSION__) (__STDC_VERSION__ = 199901L) #define ELIDABLE_INLINE inline #else #define ELIDABLE_INLINE extern inline #endif I'm not quite sure if I've got that right, though. I don't know if I need to test __STRICT_ANSI__ or not. I'm not sure if I should be testing for gnu99 mode as well as std99 or not. I want to match the exact conditions that are going to be tested to invoke the new standard behaviour; is this going to do it? ___ In gcc-4.3-20070601, a new problem came up. gcc.dg/cpp/trigraphs.c fails due to problems here in cygwin/newlib stdio.h, even with the change suggested above. Tim Prince Tim Prince
Re: When was decimal floating point added to gcc?
On Sun, Jun 03, 2007 at 02:41:57PM +0200, Gerald Pfeifer wrote: On Sun, 3 Jun 2007, Ben Elliston wrote: Are they mentioned in any gcc changes.html? No, they're not. They probably should be. Do you think we could talk the submitters/maintainers into donating a patch? :-) Support for the decimal floating point C extension could be mentioned in the release notes for GCC 4.2, but there it's only supported for powerpc*-linux and x86*-linux and only if requested at configure time. The ABI for powerpc*-linux has changed since then, and the representation will (has?) changed for x86*-linux. Is this worth documenting for 4.2? Janis
Re: When was decimal floating point added to gcc?
On Mon, Jun 04, 2007 at 01:23:16PM -0700, Janis Johnson wrote: On Sun, Jun 03, 2007 at 02:41:57PM +0200, Gerald Pfeifer wrote: On Sun, 3 Jun 2007, Ben Elliston wrote: Are they mentioned in any gcc changes.html? No, they're not. They probably should be. Do you think we could talk the submitters/maintainers into donating a patch? :-) Support for the decimal floating point C extension could be mentioned in the release notes for GCC 4.2, but there it's only supported for powerpc*-linux and x86*-linux and only if requested at configure time. The ABI for powerpc*-linux has changed since then, and the representation will (has?) changed for x86*-linux. Is this worth documenting for 4.2? DFP doesn't really work for x86*-linux unitl Uros fixed a bunch of back-end/middle-end bugs in 4.3. H.J.
gcc-4.1-20070604 is now available
Snapshot gcc-4.1-20070604 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070604/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 125321 You'll find: gcc-4.1-20070604.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070604.tar.bz2 C front end and core compiler gcc-ada-4.1-20070604.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070604.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070604.tar.bz2 C++ front end and runtime gcc-java-4.1-20070604.tar.bz2 Java front end and runtime gcc-objc-4.1-20070604.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070604.tar.bz2The GCC testsuite Diffs from 4.1-20070528 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: Fixed-point branch?
-Original Message- From: Mark Mitchell [mailto:[EMAIL PROTECTED] Sent: Thursday, May 31, 2007 9:05 AM To: Joseph S. Myers Cc: Fu, Chao-Ying; Richard Henderson; GCC Subject: Re: Fixed-point branch? Joseph S. Myers wrote: I haven't examined it. When the branch maintainers consider it ready to merge I hope a proposal along the lines of the DFP one http://gcc.gnu.org/ml/gcc/2005-11/msg01128.html will be posted (see also subsequent discussion in that thread, and on the submitted patches). I would like to avoid the situation in which Chao-Ying et. al. work hard to come up with a plan, factor the patches, etc., and then we decide that the code is not going to be ready for 4.3. I had originally pushed this work back to 4.4, but as 4.3's been delayed, perhaps there's an opportunity for it in 4.3. If, however, the work isn't ready, then I'd rather not take up a lot of Chao-Ying's time now; instead, we can just wait for 4.4 to get closer. At the same time, of course, there's not much point in you investing in looking at the branch if Chao-Ying doesn't think it's ready. So, let's do this: 1. Chao-Ying, would you please work on any remaining issues that you feel need resolution. Then, post your merge plan, ala DFP. Yes. We will work on remaining issues and post our merge plan. 2. Joseph, at that point, would you please invest a a little bit of time (a couple of hours) to look at the branch, and provide some feedback? Please provide comments to Chao-Ying, and also please let me know whether you think the work is nearly ready for inclusion? Maybe you could first check if new machine modes, new TREE structures (a saturating bit, fixed-point type, fixed-point constant), new RTL structures (fixed-point constant and operators) are ok. Thanks a lot! Regards, Chao-ying
Re: current gcc trunk testsuite failure on cygwin: Assembler messages: Warning: end of file in string; '' inserted: Warning: .stabs: missing comma
[EMAIL PROTECTED] wrote: phew, a few of the cygwin failures show up like this: Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o 20001226-1.o /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c (timeout = 300) spawn /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o 20001226-1.o /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s: Assembler messages: /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of file in string; '' inserted /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs: missing comma Windows XP Pro/SP2 cygwin cygwin 1.5.24-2 (with D Korn's stdio.h patch to newlib) trigraphs.c also failed for me for the first time, objecting to the patched version of stdio.h.
Re: [OT] Re: Git repository with full GCC history
Jan-Benedict Glaw wrote: Come visit git.infradead.org and its GCC development fork. *cough* No reason to fork. At least I'm just too used to GIT these days and like it quite a lot, that's why I work on getting the toolchain repos converted (and kept up-to-date!) somewhere as GIT repos. Err... Of course I was just joking. This just eases the pain keeping those patches up-to-date in some branches, that aren't yet ready for merging. Indeed, but if we moved the git repository to gcc.gnu.org it could also be used for pushing patches to the centralized GCC repository. For everyday development, I'd very much prefer using Git than Subversion. -- // Bernardo Innocenti \X/ http://www.codewiz.org/
libjava is a train wreck.
Can someone explain why libjava *must* commit binary files to the repository? A merge of trunk to the fortran-experiments branch generated 70 conflicts that I need to resolve. This is a complete waste of time that would have been spent towards cutting a diff of the branch against trunk for patch submission! -- Steve
[Bug target/32201] New: [4.3 Regression] Can not allocate %xmm0 register for variable blend insn
Currently, it is not possible to use SSE 4.1 variable blend instructions in asm
statements. These instructions require the third argument to be in %xmm0, but
gcc fails to allocate correct register even when (new) z constraint is used.
--cut here--
typedef float V4SFmode __attribute__((vector_size(16)));
V4SFmode t (V4SFmode a, V4SFmode b, V4SFmode c)
{
V4SFmode ret;
asm (blenvdps %0, %2, %3 : =x (ret) : 0 (a), x (b), z (c));
return ret;
}
--cut here--
gcc -O1 -msse
prxxx.c: In function 't':
prxxx.c:7: error: can't find a register in class 'SSE_FIRST_REG' while
reloading 'asm'
prxxx.c:7: error: 'asm' operand has impossible constraints
--
Summary: [4.3 Regression] Can not allocate %xmm0 register for
variable blend insn
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ssemmx, ra
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
OtherBugsDependingO 32189
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201
[Bug target/32201] Can not allocate %xmm0 register for variable blend insn
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 07:22 --- How can this be a regression if the constraint is new? Also it seems like you could use register asm(xmm0) to get the correct register to be used. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 Regression] Can not|Can not allocate %xmm0 |allocate %xmm0 register for |register for variable blend |variable blend insn |insn http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201
[Bug target/32201] Can not allocate %xmm0 register for variable blend insn
--- Comment #2 from ubizjak at gmail dot com 2007-06-04 07:39 --- (In reply to comment #1) How can this be a regression if the constraint is new? This is the same failure as PR32189, and that one is marked as a regression. Also it seems like you could use register asm(xmm0) to get the correct register to be used. But please note that c argument is passed to the function via xmm2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201
[Bug target/32201] Can not allocate %xmm0 register for variable blend insn
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-04 07:50 ---
Also it seems like you could use register asm(xmm0) to get the correct
register to be used.
But please note that c argument is passed to the function via xmm2.
So this is why GCC has register asm() extension is to get the correct register
to be used. The code would look like:
typedef float V4SFmode __attribute__((vector_size(16)));
V4SFmode t (V4SFmode a, V4SFmode b, V4SFmode c)
{
V4SFmode ret;
register V4SFmode c1 asm(xmm0);
c1 = c;
asm (blenvdps %0, %2, %3 : =x (ret) : 0 (a), x (b), x (c1));
return ret;
}
Since c1 is already in xmm0, the register allocator knows it cannot use a as
xmm0 so there is still a move before the other move and after the asm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201
[Bug target/32201] Can not allocate %xmm0 register for variable blend insn
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-04 07:58 --- Note local allocate should be able to figure the z constraint is only one register and assign it to that pesdu-register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201
[Bug target/32201] Can not allocate %xmm0 register for variable blend insn
--- Comment #5 from ubizjak at gmail dot com 2007-06-04 08:06 --- Created an attachment (id=13655) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13655action=view) Local alloc RTL dump RTL dump of .c.163r.lreg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201
[Bug middle-end/30537] [4.3 regression] ICE with -fno-unit-at-a-time an inlining
--- Comment #4 from jbglaw at lug-owl dot de 2007-06-04 08:18 --- That was already known in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563 ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30537
[Bug libgomp/32193] Upgrading GNU/Linux to libc6_2.6~20070518-2 breaks libgomp make - FIX given
--- Comment #4 from rob1weld at aol dot com 2007-06-04 08:30 --- Results: Results for 4.3.0 20070602 (libc6_2.3.6.ds1-13) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00168.html Results for 4.3.0 20070602 (libc6_2.6~20070518-2) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00169.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193
[Bug fortran/32202] New: Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f
Please read first portion of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193 to see the where and how of obtaining and installing new libc6, then come back here. After upgrading my library I did a diff of the make -i check test results of the build before I upgraded and after I upgraded. It was identical except for this: # diff -Naur ../gcc-4_3-build-libc6_2.3.6/summary ../gcc-4_3-build-libc6_2.6/summary --- ../gcc-4_3-build-libc6_2.3.6/summary2007-06-02 15:10:51.0 -0700 +++ ../gcc-4_3-build-libc6_2.6/summary2007-06-03 04:40:17.0 -0700 @@ -119,11 +119,12 @@ FAIL: gfortran.dg/open_errors.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/open_errors.f90 -O3 -g execution test FAIL: gfortran.dg/open_errors.f90 -Os execution test +FAIL: gfortran.dg/secnds.f -O3 -fomit-frame-pointer execution test === gfortran Summary === -# of expected passes 18236 -# of unexpected failures 16 +# of expected passes 18235 +# of unexpected failures 17 # of expected failures 8 # of unsupported tests 16 /opt/gcc-4_3-build/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070602 (experimental) The gfortran.dg/secnds.f test did not fail prior to my upgrade. -- Summary: Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32202
[Bug fortran/32202] Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 08:37 --- No need because this failure is a random failure anyways. *** This bug has been marked as a duplicate of 32057 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32202
[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-04 08:37 --- *** Bug 32202 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug fortran/32202] Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f
--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-04 08:44 --- Subject: Re: Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f No need because this failure is a random failure anyways. Afterall not so random: most of the failures are due to the fact that secnds(x) and dat* in the tests are computed in different ways leading to different rounding errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32202
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #7 from rob1weld at aol dot com 2007-06-04 08:58 --- [EMAIL PROTECTED] IEEE 754 does not discuss any of the functions you list above. In fact, IEEE 754 places requirements on exactly one function in libm, and that is sqrt(), which must be exact in all rounding modes. I did a search of this document for sqrt. Adobe reader says the word is not there. DRAFT Standard for Floating-Point Arithmetic P754 - Draft 1.3.0 Modified at 17:15 GMT on February 23, 2007 http://www.validlab.com/754R/drafts/archive/2007-02-23.pdf I realize that is a draft, perhaps there is an ommision. Here is a clip from the document: Introduction ... PURPOSE: This standard provides a discipline for performing floating-point computation that yields results independent of whether the processing is done in hardware, software, or a combination of the two. For operations specified in the normative part of this standard, numerical results and exceptions are uniquely determined by the values of the input data, sequence of operations, and destination formats, all under user control. This standard defines a family of commercially feasible ways for systems to perform binary and decimal floating-point arithmetic. Among the desiderata that guided the formulation of this standard were a)Facilitate movement of existing programs from diverse computers to those that adhere to this standard. b)Enhance the capabilities and safety available to users and programmers who, though not expert in numerical methods, may well be attempting to produce numerically sophisticated programs. However, we recognize that utility and safety are sometimes antagonists. c)Encourage experts to develop and distribute robust and efficient numerical programs that are portable, by way of minor editing and recompilation, onto any computer that conforms to this standard and possesses adequate capacity. When restricted to a declared subset of the standard, these programs should produce identical results on all conforming systems. d)Provide direct support for 1)Execution-time diagnosis of anomalies 2)Smoother handling of exceptions 3)Interval arithmetic at a reasonable cost. e)Provide for development of 1)Standard elementary functions such as exp and cos 2)Very high precision (multiword) arithmetic 3)Coupling of numerical and symbolic algebraic computation. f)Enable rather than preclude further refinements and extensions. 2. References The following referenced documents are indispensable for the application of this standard: ANSI/IEEE Std 7541985 R1990, IEEE Standard for Binary Floating-Point Arithmetic.[1] ISO/IEC 9899, Second edition 1999-12-01, Programming languages C.[2] [1] IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA. [2] ISO publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varembé, CH-1211, Genève 20, Switzerland/Suisse. ISO publications are also available in the United States from the Sales Department, American National Standards Institute, 11 West 42nd Street, 13th Floor, New York, NY 10036, USA. Annex B Expression evaluation B.3 Reproducible results Languages should provide means for programmers to specify reproducible results that are identical on all platforms supporting that language and this standard, for operations completely specified by this standard. Annex D Elementary transcendental functions All the directives in this annex are optional. ... Functions implemented as directed here have the properties that they preserve monotonicity and reproduce results exactly from implementation to implementation. ... Languages should define which functions are required or recommended to be provided in correctly-rounded versions. When a language chooses not to specify a function as conforming to this annex, each implementation should document the available domain, exceptional cases, worst-case accuracies achieved, and indicate whether the accuracies are proven or measured for a subset of inputs. --- Please Note: Languages should provide means for programmers to specify reproducible results that are identical on all platforms supporting that language and this standard, for operations completely specified by this standard. When a language chooses not to specify a function as conforming to this annex, each implementation should document the available domain, exceptional cases, worst-case accuracies achieved, and indicate whether the accuracies are proven or measured for a subset of inputs. I understand should is defined in the document in section 3.1.4. You said: IEEE 754 does not discuss any of the functions you list above. In fact, IEEE 754 places requirements on exactly one function in libm, and that is sqrt(), which must be exact in all rounding modes. I say: The language's standard chooses the functions it will support. IE: BASIC does not have to support
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #8 from rob1weld at aol dot com 2007-06-04 09:07 --- [EMAIL PROTECTED] Can you suggest a download URL? Mine is from ATT. I didn't save the URL. Your output is certainly a few pages shorter than mine. There is a Paranoia test included in Ucbtest that has output similar to what I get - the URL for that is given above. What hardware are you using and which version of libm is installed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #9 from rob1weld at aol dot com 2007-06-04 09:16 --- There is a wiki here - your contributions are appreciated. http://en.wikipedia.org/wiki/IEEE_754r -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug fortran/32203] New: Support the vendor intrinsic function timef()
As requested: http://gcc.gnu.org/ml/fortran/2007-06/msg00013.html timef() allows one easily to track elapsed time. It is supported by a couple of vendors such as IBM and Intel, but not by gfortran, g95, g77, sunf95, NAG f95. http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=/com.ibm.xlf101l.doc/xlflr/sup-timef.htm The timef function returns the elapsed time in milliseconds since the first call to timef. The accuracy of an XL Fortran timing function is operating system dependent. Returns a REAL(8) and 0d0 on the first call. Variant form: timef_delta() [which is not supported by e.g. ifort] http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=/com.ibm.xlf101l.doc/xlflr/sup-timefdelta.htm -- Summary: Support the vendor intrinsic function timef() Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32203
[Bug fortran/32195] [regression] ICE in get_array_ctor_strlen
--- Comment #1 from dominiq at lps dot ens dot fr 2007-06-04 11:25 --- As far as I can tell this bug seems to affect only darwin7. The ICE occurs with RESHAPE and EOSHIFT with character arrays and a third optional argument: The following code character(len=1) :: tempn(1,2) character(len=1),allocatable :: foo(:,:), bar(:,:) integer :: tempi(1,2) tempn = 'a' tempi = 1 x = 0 allocate(foo(3,0),bar(-2:-4,7:9)) print *, reshape(tempn(:,:),(/2,1/)) print *, reshape((/1,2,3,4,5,6/),(/3,5/),(/-1,-2/),(/2,1/)) print *, reshape((/'A','B','C','D','E','F','G','H','I','J','K','L'/), (/3,5/),order=(/2,1/),pad=(/'a'/)) print *, eoshift(tempi,(/1,1/),boundary=(/2,3/)) ! print *, eoshift(tempn,(/1,1/),boundary=(/'b','c'/)) print *, reshape(tempi,(/3,3/),order=(/1,2/),pad=(/2/)) ! print *, reshape(tempn,(/3,3/),order=(/1,2/),pad=(/'b'/)) end compiles fine, but any of the commented lines trigger the ICE. Does it ring some bell? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32195
[Bug c++/32204] New: friend from global namespace in template class ignored
X-Bugzilla-Reason: CC
First: I apologize if this report is missing something but I did not find
enough information in the guidelines to be more accurate. Furthermore, I have
only gcc 4.1.2 prerelease available (from Suse Linux 10.2), so I will be glad
if somebody tells me the bug has been fixed in a later version.
The bug is related to 8355 and 9230, but I guess it's different.
The following program does not compile; depending on the kind of invocation of
'f' 3 different errors occur (where the messages of 1 and 3 contradict to each
other, see below):
namespace A { template class PIX class B; }
void f(A::Bint);
template class PIX class A::B {
friend void ::f(A::Bint);
PIX z;
};
void f(A::Bint i) { int a = i.z; }
int main() {
A::Bint b;
f(b); // 1. error: f is ambiguous (no, there is no 2nd declaration!)
::f(b); // 2. error: z is private (yes, but 'f' is a friend)
A::f(b); // 3. error: f is not a member of A (of course)
}
The only invocation that should yield an error is no. 3. No. 2 should
definitely work, and I guess the double colon for the global namespace should
be unnecessary anywhere.
No error occurs if I transfer 'f' from the global namespace to another one (C):
namespace A { template class PIX class B; }
namespace C { void f(A::Bint); }
template class PIX class A::B {
friend void C::f(A::Bint);
PIX z;
};
void C::f(A::Bint i) { int a = i.z; }
int main() {
A::Bint b;
C::f(b); // OK
using namespace C;
f(b); // OK
}
Another work-around is to make 'f' an template function.
--
Summary: friend from global namespace in template class ignored
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: klaus dot kretschel at dlr dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32204
[Bug target/32191] ICE with complex __float128
--- Comment #8 from ubizjak at gmail dot com 2007-06-04 12:27 --- A bit of debugging leads to following findings: build_common_builtin_nodes() defines supported complex mul/div functions depending on lang_hooks.types.type_for_mode(). This langhook defaults to c_common_type_for_mode(). c_common_type_for_mode() as defined in c-common.c() handles complex modes by breaking non-standard modes into fundamental type, passing them again through c_common_type_for_node(): inner_mode = GET_MODE_INNER (mode); inner_type = c_common_type_for_mode (inner_mode, unsignedp); if (inner_type != NULL_TREE) return build_complex_type (inner_type); If this fundamental type is non-standard, then: for (t = registered_builtin_types; t; t = TREE_CHAIN (t)) if (TYPE_MODE (TREE_VALUE (t)) == mode) return TREE_VALUE (t); and with returned fundamental type, we return build_complex_type (inner_type). So the main problem is, that TFmode is not defined at this point. TFmode is defined through targetm.init_builtins() target hook, and we call this target hook just after the call to build_common_builtin_nodes(). Do we need to switch the calls at the end of c_define_builtins() function, defined in c-common.c? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191
[Bug c++/32182] [4.2 Regression] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug c++/32205] New: defined but not used warning given or not depending on other errors
Consider the following code:
% cat unused.cpp
static int GetFoo() { return 17; }
static int foo = GetFoo();
void bar()
{
}
This compiles without warnings:
% g++ -Wall -c unused.cpp
%
However if any error is introduced, like e.g. removing the closing brace of the
bar() function, then we get both the (expected) error message and (less
expected) warning:
% g++ -Wall -c unused.cpp
unused.cpp: In function 'void bar()':
unused.cpp:6: error: expected `}' at end of input
unused.cpp: At global scope:
unused.cpp:3: warning: 'foo' defined but not used
I don't know if the warning should or not be given (actually I'm glad to not
have it in my code as my equivalent of GetFoo() has side effects) but it seems
strange that the fact whether it's given or not depends on whether there are
any other errors in the code.
I realize this is not very important (hence the choice of severity) but I
wanted to let you know about it in case this indicates some more serious
problem with issuing this warning. Please feel free to ignore this bug report
if it doesn't.
Thanks!
--
Summary: defined but not used warning given or not depending on
other errors
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32205
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- Comment #12 from mec at google dot com 2007-06-04 13:35 --- Verified with my two test programs with snapshot gcc-4.3-20070601. Thanks for the fast fix! -- mec at google dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #3 from manu at gcc dot gnu dot org 2007-06-04 13:51 --- Likely, the code for parsing template arguments is not clever enough to stop as soon as something goes awry and report it correctly. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Summary|bad diagnostic |wrong error recovery on ||parsing template arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #165 from rguenth at gcc dot gnu dot org 2007-06-04 14:02 --- The lates patch fixes the FreePOOMA testsuite regressions. I'll give it a performance testing spin on vangelis tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #4 from igodard at pacbell dot net 2007-06-04 14:27 --- Well, in my ignorance, I'd say that the symptoms are consistent with scanning forward to the next , regardless of what gets scanned over, such an unmatched or statement-lists. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-06-04 15:28
---
solution_set_add () looks like the culprit (thx micha). So, the following will
fix it in case we have offsets only from COMPONENT_REFs, not from regular
pointer arithmetic (which is not true):
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 125310)
+++ tree-ssa-structalias.c (working copy)
@@ -715,13 +715,10 @@ solution_set_add (bitmap set, unsigned H
less than end. Otherwise, it is globbed to a single
variable. */
- if ((get_varinfo (i)-offset + offset) get_varinfo (i)-fullsize)
+ if (get_varinfo (i)-offset + get_varinfo (i)-size - 1 = offset
+ get_varinfo (i)-offset + offset get_varinfo (i)-fullsize)
{
- unsigned HOST_WIDE_INT fieldoffset = get_varinfo (i)-offset +
offset;
- varinfo_t v = first_vi_for_offset (get_varinfo (i), fieldoffset);
- if (!v)
- continue;
- bitmap_set_bit (result, v-id);
+ bitmap_set_bit (result, i);
}
else if (get_varinfo (i)-is_artificial_var
|| get_varinfo (i)-has_union
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-06-04 15:45
---
We can make it safe if we only really handle + in pointer arithmetic. Like
with
@@ -3258,7 +3255,7 @@ handle_ptr_arith (VEC (ce_s, heap) *lhsc
unsigned int i = 0;
unsigned int j = 0;
VEC (ce_s, heap) *temp = NULL;
- unsigned int rhsoffset = 0;
+ unsigned HOST_WIDE_INT rhsoffset = 0;
if (TREE_CODE (expr) != PLUS_EXPR
TREE_CODE (expr) != MINUS_EXPR)
@@ -3269,9 +3266,12 @@ handle_ptr_arith (VEC (ce_s, heap) *lhsc
get_constraint_for (op0, temp);
if (POINTER_TYPE_P (TREE_TYPE (op0))
- TREE_CODE (op1) == INTEGER_CST
+ host_integerp (op1, 1)
TREE_CODE (expr) == PLUS_EXPR)
{
+ if ((TREE_INT_CST_LOW (op1) * BITS_PER_UNIT) / BITS_PER_UNIT
+ != TREE_INT_CST_LOW (op1))
+ return false;
rhsoffset = TREE_INT_CST_LOW (op1) * BITS_PER_UNIT;
}
else
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)
--- Comment #15 from sje at gcc dot gnu dot org 2007-06-04 15:58 --- Subject: Bug 31733 Author: sje Date: Mon Jun 4 15:58:12 2007 New Revision: 125312 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125312 Log: PR target/31733 * cfgrtl.c (rtl_verify_flow_info): Skip notes when looking for barrier. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgrtl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31733
[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)
--- Comment #16 from sje at cup dot hp dot com 2007-06-04 16:03 --- Fixed now. All testcases are working with ToT. -- sje at cup dot hp dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31733
[Bug fortran/32206] New: gfortran testsuite - unexpected failures
Running make -k check-fortran on an Intel Macintosh generated unexpected failures - Test Run By dir on Mon Jun 4 07:56:01 2007 Native configuration is i386-apple-darwin8.9.1 === gfortran tests === Schedule of variations: unix Running target unix Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target. Using /Users/dir/gfortran/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/secnds-1.f -O3 -fomit-frame-pointer execution test Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.dg/gomp/gomp.exp ... Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.dg/vect/vect.exp ... Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp ... Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ... === gfortran Summary === # of expected passes18134 # of unexpected failures1 # of expected failures 8 # of unsupported tests 46 /Users/dir/gfortran/ibin/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070604 (experimental) -- Summary: gfortran testsuite - unexpected failures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: i386-apple-darwin8.9.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32206
[Bug fortran/32206] gfortran testsuite - unexpected failures
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 16:11 --- Only semi unexpected, the issue hasto do with fp rounding, *** This bug has been marked as a duplicate of 32057 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32206
[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-04 16:11 --- *** Bug 32206 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug c/32207] New: inconsistent/missed warnings about address of 'x'.
the following testcase express one condition in three different ways.
in fact, gcc produces only two different warnings.
extern void z();
void f() { if ( z ) z(); }
void g() { if ( z != 0 ) z(); }
void h() { if ( z != (void*)0 ) z(); }
t.c: In function 'f':
t.c:2: warning: the address of 'z' will always evaluate as 'true'
t.c: In function 'g':
t.c:3: warning: the address of 'z' will never be NULL
--
Summary: inconsistent/missed warnings about address of 'x'.
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32207
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #4 from aldot at gcc dot gnu dot org 2007-06-04 17:20 --- fx, are you still working on this? yet another reason why -M as an alias for -J should be dropped and instead proper -M dependency handling should be added is this: $ echo end foo.f90 gfortran -o main foo.f90 -v -M Segmentation fault i.e. it isn't user-safe with 4.1.2, 4.2.0 and trunk. -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #10 from kargl at gcc dot gnu dot org 2007-06-04 17:32 --- (In reply to comment #7) [EMAIL PROTECTED] IEEE 754 does not discuss any of the functions you list above. In fact, IEEE 754 places requirements on exactly one function in libm, and that is sqrt(), which must be exact in all rounding modes. I did a search of this document for sqrt. Adobe reader says the word is not there. DRAFT Standard for Floating-Point Arithmetic P754 - Draft 1.3.0 Modified at 17:15 GMT on February 23, 2007 http://www.validlab.com/754R/drafts/archive/2007-02-23.pdf Compare the current working draft of the revised IEEE 754 standard to the standing Standard is similar to a comparison of a Boeing 747 to the Wright brothers' aircraft. The standing IEEE 754 standard is 23 pages in total length. Here is the text concerning square root: 5.2. Square Root The square root operation shall be provided in all supported formats. The result is defined and has a positive sign for all operands = 0, except that sqrt(0) shall be 0. The destination format shall be at least as wide as the operand's. The result shall be rounded as specified in Section 4. There are a few functions described in the Appendix, which contains this disclaimer: (This Appendix is not a part of ANSI/IEEE Std 754-1985, IEEE Standard for Binary Floating-Point Arithmetic.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-04 17:39 --- (In reply to comment #4) fx, are you still working on this? Not actively. It's probably not so hard, though: read the file, like we do with -fsyntax-only mode, and parse #file headers. yet another reason why -M as an alias for -J should be dropped and instead proper -M dependency handling should be added is this: $ echo end foo.f90 gfortran -o main foo.f90 -v -M Segmentation fault That's another one. File a new PR (it's probably a simple check that's missing in gfc_handle_module_path_options()). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug c/32191] ICE with complex __float128
--- Comment #9 from ubizjak at gmail dot com 2007-06-04 17:42 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00188.html (Please do not open new bugreport for missing _multc3 and _divtc3. These will be added as a follow-up patch). -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg00188.html Component|target |c Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191
[Bug c/32191] ICE with complex __float128
-- ubizjak at gmail dot com changed: What|Removed |Added CC|ubizjak at gmail dot com| AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-06-03 09:22:57 |2007-06-04 17:43:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #11 from theodore dot papadopoulo at sophia dot inria dot fr 2007-06-04 18:12 --- (In reply to comment #8) I suspect (unless I'm overlooked something) that this problem cause wrong statistics when using jointly the -fopenmp and -profile-* flags. I tried that and seen messages saying that the counters are corrupted (negative counters)... Still need to find a small testcase though. If I'm true, at the very least, the flags should error when used in conjunction (for this I can do a patch, if this is the right solution). Correcting this in this case should be easy (multiplicate the counters by the number of threads and join them at dump time), but that's probably beyond my gcc hacking capabilities... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug libstdc++/32208] New: Patch for 32158 has bad code in std::vector::_M_fill_initialize
[EMAIL PROTECTED]:~/exp-43-redux$ cat vector-fill.cc // Copyright 2007, Google Inc. All rights reserved. // Author: [EMAIL PROTECTED] (Michael Chastain) #include vector std::vectorint my_vector (117); === [EMAIL PROTECTED]:~/exp-43-redux$ /home/mec/gcc-4.3-20070601/install/bin/g++ -Wall -S vector-fill.cc /home/mec/gcc-4.3-20070601/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h: In member function 'int std::vector_Tp, _Alloc::_M_fill_initialize(size_t, const _Tp) [with _Tp = int, _Alloc = std::allocatorint]': /home/mec/gcc-4.3-20070601/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h:832: warning: control reaches end of non-void function === This is from: http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/stl_vector.h?r1=124243r2=125223 Trivial lack of void. === Also, shouldn't there also be an error about lack of return type for _M_fill_initialize? -- Summary: Patch for 32158 has bad code in std::vector::_M_fill_initialize Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mec at google dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32208
[Bug c/32209] New: Boot failure Comparing stages 2 and 3
Comparing stages 2 and 3 warning: ./cc1-checksum.o differs Bootstrap comparison failure! ./cfgloopanal.o differs ./expmed.o differs ./df-problems.o differs ./combine.o differs ./ebitmap.o differs ./emit-rtl.o differs ./reload.o differs ./cgraphunit.o differs ./c-typeck.o differs ./recog.o differs ./cfgrtl.o differs ./tree-into-ssa.o differs ./tree-ssa-loop-ivopts.o differs ./cfglayout.o differs ./tree-tailcall.o differs ./tree-ssa-loop-ivcanon.o differs ./build/gengtype.o differs ./build/genpreds.o differs ./build/genoutput.o differs ./build/genemit.o differs ./build/genextract.o differs ./build/genautomata.o differs ./fold-const.o differs ./cse.o differs ./cfgexpand.o differs ./gcc.o differs ./see.o differs ./matrix-reorg.o differs ./tree-if-conv.o differs ./c-lex.o differs ./tree-ssa-reassoc.o differs ./c-format.o differs ./dwarf2out.o differs ./attribs.o differs ./tree-cfg.o differs ./tree-ssa-address.o differs ./tree-ssa.o differs ./tree-vrp.o differs ./modulo-sched.o differs ./dominance.o differs ./tree-ssa-phiopt.o differs ./lambda-code.o differs ./insn-recog.o differs ./tree-vect-transform.o differs ./tree-scalar-evolution.o differs ./reg-stack.o differs ./c-common.o differs ./tree-ssa-alias.o differs ./bt-load.o differs ./tree-ssa-forwprop.o differs ./haifa-sched.o differs ./mode-switching.o differs ./tree-dump.o differs ./final.o differs ./tree-data-ref.o differs ./global.o differs ./tree-ssa-sink.o differs ./diagnostic.o differs ./insn-attrtab.o differs ./cfgcleanup.o differs ./ipa-type-escape.o differs ./flow.o differs ./gcov.o differs ./gcse.o differs ./tree-vectorizer.o differs ./simplify-rtx.o differs ./loop-iv.o differs ./integrate.o differs ./tree-ssa-loop-prefetch.o differs ./tree-ssa-coalesce.o differs ./ipa-prop.o differs ./tree-outof-ssa.o differs ./tree-ssa-threadupdate.o differs ./tree-ssa-ccp.o differs ./tree-ssa-loop-niter.o differs ./tree-ssa-dce.o differs ./tree-ssa-dse.o differs ./tree-predcom.o differs ./postreload.o differs ./tree-ssa-pre.o differs ./tree-ssa-ter.o differs ./tree.o differs ./reload1.o differs ./tree-ssanames.o differs ./tree-ssa-structalias.o differs ./builtins.o differs ./c-decl.o differs ./tree-ssa-propagate.o differs ./profile.o differs ./omega.o differs ./bb-reorder.o differs ./cfgloopmanip.o differs ./value-prof.o differs ./gtype-desc.o differs ./ggc-common.o differs ./sched-rgn.o differs ./calls.o differs ./optabs.o differs ./tree-vect-analyze.o differs ./gimplify.o differs ./cfgloop.o differs ./varasm.o differs ./tree-ssa-math-opts.o differs ./regmove.o differs ./var-tracking.o differs ./regclass.o differs ./sched-deps.o differs ./loop-unroll.o differs ./tracer.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/usv/gcc_r43/build.5' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/usv/gcc_r43/build.5' make: *** [bootstrap] Error 2 This occurs on two different machines, with many more mis-comparisons for c,c++,fortran Did not occur saturday and early sunday. -- Summary: Boot failure Comparing stages 2 and 3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: i686-pc-gnu-org GCC host triplet: i686-pc-gnu-org GCC target triplet: i686-pc-gnu-org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug c/32191] ICE with complex __float128
--- Comment #10 from uros at gcc dot gnu dot org 2007-06-04 20:07 --- Subject: Bug 32191 Author: uros Date: Mon Jun 4 20:07:37 2007 New Revision: 125314 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125314 Log: PR c/32191 * gcc/c-common.c (c_define_builtins): Call targetm.init_builtins () before build_common_builtin_nodes (). testsuite/ChangeLog: PR c/32191 * gcc.dg/pr32191.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr32191.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191
[Bug c/32191] ICE with complex __float128
--- Comment #11 from ubizjak at gmail dot com 2007-06-04 20:08 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191
[Bug middle-end/32209] Boot failure Comparing stages 2 and 3
--- Comment #1 from andreast at gcc dot gnu dot org 2007-06-04 20:09 --- can you post the config flags? Did you may use --disable-checking ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug c++/32210] New: Wrong alignment of struct members where one member is bitfield exceeding its type.
In the following testcase:
#include new
#include stdlib.h
#include stdio.h
class c1
{
public:
char m1 : 17;
//char m2;
};
void printbytes(void * p, int size)
{
printf(Printing an object on %i bytes\n,size);
for (int i=0; isize; i++)
printf(Byte %i is %i\n,i, ((char*)p)[i]);
printf(Finish printing\n%d\n, __alignof__(c1));
}
int
main (int argc, char **argv) {
c1 * obj = new c1;
printf(Here\n);
obj-m1 = 1;
//obj-m2 = 1;
printbytes(obj,sizeof(c1));
}
The output is:
Here
Printing an object on 4 bytes
Byte 0 is 1
Byte 1 is 0
Byte 2 is 0
Byte 3 is 0
Finish printing
2
The alignment is 2 bytes, however, according to the ABI the alignment of this
non-POD type should be 1. But, in reality the alignment is 1 because when I add
another char member m2, the output is:
Here
Printing an object on 4 bytes
Byte 0 is 1
Byte 1 is 0
Byte 2 is 0
Byte 3 is 1
Finish printing
2
--
Summary: Wrong alignment of struct members where one member is
bitfield exceeding its type.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cjain at ca dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32210
[Bug c++/32211] New: Compile error
While compiling KDE 3.5.7, this appears:
-
Making all in interfaces
make[5]: Entering directory
`/initrd/mnt/dev_save/VBProjects/passwordlinux/kde/konstruct/kde/kdepim/work/kdepim-3.5.7/kmail/interfaces'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory
`/initrd/mnt/dev_save/VBProjects/passwordlinux/kde/konstruct/kde/kdepim/work/kdepim-3.5.7/kmail/interfaces'
Making all in .
make[5]: Entering directory
`/initrd/mnt/dev_save/VBProjects/passwordlinux/kde/konstruct/kde/kdepim/work/kdepim-3.5.7/kmail'
if /bin/sh ../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I.. -I../libkmime -I../libkpgp -I../libkdenetwork -I../libkdepim
-I../libkpimidentities -I../libemailfunctions -I../libksieve -I../mimelib
-I../certmanager/lib -I../certmanager/lib/ui -I../indexlib -I../ktnef -I..
-I/mnt/home/VBProjects/passwordlinux/kde3.5.7/include
-I/mnt/home/VBProjects/passwordlinux/kde3.5.7/include -I../libkdepim
-I/mnt/home/VBProjects/passwordlinux/kde3.5.7/include -I/usr/X11R7/include
-DQT_THREAD_SUPPORT -I/mnt/home/VBProjects/passwordlinux/kde3.5.7/include
-I/usr/X11R6/include -I/mnt/home/VBProjects/passwordlinux/kde3.5.7/include
-I/usr/X11R6/include -D_REENTRANT -D_FILE_OFFSET_BITS=64 -Wno-long-long
-Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts
-Wall -W -Wpointer-arith -O2
-I/mnt/home/VBProjects/passwordlinux/kde3.5.7/include -I/usr/X11R6/include
-L/mnt/home/VBProjects/passwordlinux/kde3.5.7/lib -L/usr/X11R6/lib -O2 -pipe
-I/mnt/home/VBProjects/passwordlinux/kde3.5.7/include -I/usr/X11R6/include
-L/mnt/home/VBProjects/passwordlinux/kde3.5.7/lib -L/usr/X11R6/lib -O2 -pipe
-Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE
-DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT
libkmailprivate_la.all_cpp.lo -MD -MP -MF
.deps/libkmailprivate_la.all_cpp.Tpo -c -o libkmailprivate_la.all_cpp.lo
libkmailprivate_la.all_cpp.cpp; \
then mv -f .deps/libkmailprivate_la.all_cpp.Tpo
.deps/libkmailprivate_la.all_cpp.Plo; else rm -f
.deps/libkmailprivate_la.all_cpp.Tpo; exit 1; fi
In file included from libkmailprivate_la.all_cpp.cpp:4:
configuredialog.cpp: In constructor `ConfigureDialog::ConfigureDialog(QWidget*,
const char*, bool)':
configuredialog.cpp:220: warning: `__base_ctor' is deprecated (declared at
/mnt/home/VBProjects/passwordlinux/kde3.5.7/include/kcmultidialog.h:105)
In file included from libkmailprivate_la.all_cpp.cpp:13:
kmfoldertree.cpp: In member function `virtual void
KMFolderTree::contentsDropEvent(QDropEvent*)':
kmfoldertree.cpp:1449: warning: `keyboardModifiers' is deprecated (declared at
/mnt/home/VBProjects/passwordlinux/kde3.5.7/include/kapplication.h:1069)
kmfoldermbox.cpp: At global scope:
kmfoldermbox.cpp:260: warning: unused parameter 'owner'
kmfoldermbox.cpp:93: warning: unused parameter 'owner'
{standard input}: Assembler messages:
{standard input}:94352: Warning: end of file not at end of a line; newline
inserted
{standard input}:94938: Error: suffix or operands invalid for `add'
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[5]: *** [libkmailprivate_la.all_cpp.lo] Error 1
make[5]: Leaving directory
`/initrd/mnt/dev_save/VBProjects/passwordlinux/kde/konstruct/kde/kdepim/work/kdepim-3.5.7/kmail'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/initrd/mnt/dev_save/VBProjects/passwordlinux/kde/konstruct/kde/kdepim/work/kdepim-3.5.7/kmail'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/initrd/mnt/dev_save/VBProjects/passwordlinux/kde/konstruct/kde/kdepim/work/kdepim-3.5.7'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/initrd/mnt/dev_save/VBProjects/passwordlinux/kde/konstruct/kde/kdepim/work/kdepim-3.5.7'
make[1]: *** [build-work/kdepim-3.5.7/Makefile] Error 2
make[1]: Leaving directory
`/initrd/mnt/dev_save/VBProjects/passwordlinux/kde/konstruct/kde/kdepim'
make: *** [dep-../../kde/kdepim] Error 2
---
g++ requests me to file a bug.
Is this a bug?
jimhap
--
Summary: Compile error
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jimmyhappyi at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32211
[Bug middle-end/32209] Boot failure Comparing stages 2 and 3
--- Comment #2 from malitzke at metronets dot com 2007-06-04 20:42 --- Confirmation on different architecture (powerpc-linux-gnu G4) doing an *.nm comparison as follows: on c-common.o 16c16 00017d5c t add_tlist --- 00017d60 t add_tlist 60c60 00018ca0 T c_add_case_label --- 00018ca4 T c_add_case_label 73c73 0001758c T c_common_type_for_mode --- 00017590 T c_common_type_for_mode 78c78 00019788 T c_expand_decl --- 0001978c T c_expand_decl 107c107 000186fc t conversion_warning --- 00018700 t conversion_warning 109c109 00018bcc T convert_and_check --- 00018bd0 T convert_and_check 139c139 00019968 T finish_fname_decls --- 0001996c T finish_fname_decls 193,194c193,194 00019818 T fname_as_string 000195d8 T fname_decl --- 0001981c T fname_as_string 000195dc T fname_decl 304c304 00017c30 t merge_tlist --- 00017c34 t merge_tlist 311c311 000179d8 t new_tlist --- 000179dc t new_tlist 350c350 00016b20 T shorten_compare --- 00016b24 T shorten_compare 367c367 000193b8 T strict_aliasing_warning --- 000193bc T strict_aliasing_warning 394,396c394,396 000191c4 T vector_types_convertible_p 00018594 T verify_sequence_points 00017e08 t verify_tree --- 000191c8 T vector_types_convertible_p 00018598 T verify_sequence_points 00017e0c t verify_tree 401,402c401,402 00017bd0 t warn_for_collisions 00017ac0 t warn_for_collisions_1 --- 00017bd4 t warn_for_collisions 00017ac4 t warn_for_collisions_1 427c427 00018a58 T warnings_for_convert_and_check --- 00018a5c T warnings_for_convert_and_check This on revision 125313. By coincidence c-common.c was changed just now. I am CC'ing people who made recent changes. -- malitzke at metronets dot com changed: What|Removed |Added CC||sje at cup dot hp dot com, ||jh at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug middle-end/32209] Boot failure Comparing stages 2 and 3
--- Comment #3 from malitzke at metronets dot com 2007-06-04 20:56 --- Took the liberty of adding Prof Sikora and the release manager, Could not add MR Zedenek Dvorak (refusla by [EMAIL PROTECTED] This seems to be a case Maintainers no doing the required bootstraps. I am amazed that nobody else caught for a number of hours. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #6 from rep dot dot dot nop at gmail dot com 2007-06-04 20:50 --- Subject: Re: gfortran should be able to output Makefile dependencies with -M* options On Mon, Jun 04, 2007 at 05:39:48PM -, fxcoudert at gcc dot gnu dot org wrote: --- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-04 17:39 --- (In reply to comment #4) fx, are you still working on this? Not actively. It's probably not so hard, though: read the file, like we do with -fsyntax-only mode, and parse #file headers. Yes, without looking i was thinking about for each file, populate a list of provides/needs mods and emit them when a file is done. yet another reason why -M as an alias for -J should be dropped and instead proper -M dependency handling should be added is this: $ echo end foo.f90 gfortran -o main foo.f90 -v -M Segmentation fault That's another one. File a new PR (it's probably a simple check that's missing in gfc_handle_module_path_options()). I did not look whether it is calling strlen on NULL or another spot in the option handling, but i will not look at the current meaning of -M, so please feel free to file this if you think it's worth noting it. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #50 from manu at gcc dot gnu dot org 2007-06-04 21:12 --- Subject: Bug 25241 Author: manu Date: Mon Jun 4 21:11:51 2007 New Revision: 125317 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125317 Log: 2007-06-04 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR testsuite/25241 testsuite/ * gcc.dg/cpp/mi1.c: Use dg-message for output that is not an error. * gcc.dg/cpp/mi5.c: Likewise. * gcc.dg/cpp/mi7.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/mi1.c trunk/gcc/testsuite/gcc.dg/cpp/mi5.c trunk/gcc/testsuite/gcc.dg/cpp/mi7.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #18 from hjl at lucon dot org 2007-06-04 21:14 --- (In reply to comment #12) Maybe someone should timings without the second reassoc. Jeff mentioned the loop optimizers cause new reassociations: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00469.html And Daniel Berlin agreed with him (but this was before a DCE was added): http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00473.html Here are SPEC CPU 2K -O2 -ffast-math differences between revision 125030 without the second reassoc and revision 125029 on Intel64: (r125030 w/o reassoc2 - r125029)/r125029 164.gzip -0.282686% 175.vpr -0.928613% 176.gcc -0.34774% 181.mcf -0.430339% 186.crafty 0.430192% 197.parser -0.231839% 252.eon -0.487013% 253.perlbmk -0.592417% 254.gap 0% 255.vortex -0.211775% 256.bzip2-1.2024% 300.twolf0.0389257% Est. SPECint_base2000-0.344149% 168.wupwise -0.881057% 171.swim -0.690449% 172.mgrid3.89688% 173.applu-4.26743% 177.mesa -2.82981% 178.galgel -2.04283% 179.art -2.65207% 183.equake -0.347222% 187.facerec 0.191791% 188.ammp -5.33402% 189.lucas1.65726% 191.fma3d0.586667% 200.sixtrack -0.405954% 301.apsi 1.47219% Est. SPECfp_base2000 -0.836636% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #19 from hjl at lucon dot org 2007-06-04 21:39 --- Can anyone show that the newly added dce_loop anything useful? Can we disable it or move it after the second reassoc? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug middle-end/32209] Boot failure Comparing stages 2 and 3
--- Comment #4 from malitzke at metronets dot com 2007-06-04 21:56 ---
Here is the build machinery used on the powerpc: There were two changes made to
prior runs that caused no boot failures:
BUILD was incresed from 11 to 12
form enable-languages c++, fortran were removed as being pointless to
demonstrate the boot failure. Note that disable-checking is active.
Onthe other two machines the build machinery is architecture and number of
processor specific other pretty much the same.
#!/bin/sh
VERSION=4.3.0
ARCH=${ARCH:-powerpc}
TARGET=$ARCH-unknown-linux-gnu
BUILD=12
TMP=/var/tmp/gcc_r43 # `mcookie`
cd $TMP
# build gcc
( mkdir -p build-$BUILD;
mkdir -p destdir-$BUILD;
cd build-$BUILD;
../gcc-$VERSION/configure \
--prefix=/usr \
--infodir=/usr/share/info \
--mandir=/usr/share/man \
--host=$TARGET \
--build=$TARGET \
--enable-__cxa_atexit \
--enable-threads=posix \
--enable-altivec \
--enable-shared \
--enable-clocale=gnu \
--enable-bootstrap \
--enable-languages=c \
--disable-nls \
--disable-checking \
--disable-werror \
--disable-multilib \
--with-ibmlongdouble \
--with-cpu=7450 \
--enable-clocale=gnu \
--with-system-zlib 21 | tee .Conf
# --with-gxx-include-dir=/usr/lib/gcc/$TARGET/$VERSION/include/g++-v4 \
# --enable-version-specific-runtime-libs \
# --includedir=/usr/lib/gcc/$TARGET/$VERSION/include \
# --bindir=/usr/$TARGET/gcc-bin/$VERSION \
# --enable-libffi \
# --enable-ffi \
# --target=$TARGET \
# --enable-mudflap \
# --enable-libgcc-math \
# --enable-secureplt \
# --enable-libgfortran \
# --disable-libmudflap gentoo\
# --datadir=/usr/share/gcc-data/$TARGET \
# --disable-dss \
# --disable-libssp gentoo\
# --disable-libunwind-exceptions \
# --enable-libssp \
# --program-suffix=-$VERS \
# --enable-libgcj-multifile \
# --with-java-home=/usr \
# --disable-libgcj \
# --enable-java-awt=gtk \
# --with-java-home=/usr/lib/jvm/java-1.4.2/jre \
# --enable-languages=c,c++,fortran,objc,obj-c++,java \
# --enable-languages=c,c++,fortran \
# --libexecdir=/usr/libexec/gcc-$VERSION \
# --with-slibdir=/usr/lib/$TARGET/$VERSION \
# --libdir=/usr/lib/$TARGET/$VERSION \
# --enable-checking=release \
# Start the build:
nice --adjustment=15 make -j2 BOOT_CFLAGS=-O2 -pipe STAGE1_CFLAGS=-O -pipe
LIBCFLAGS=-O2 -pipe \
LIBCXXFLAGS=-O2 -pipe -fno-implicit-templates \
bootstrap 21 |tee .Build
# LIBPATH=/$TARGET/$VERSION bootstrap 21 |tee -a .Build
make install DESTDIR=/$TMP/destdir-$BUILD 21 | tee .Inst
nice --adjustment=18 make -j2 -i check 21 |tee .Check
)
echo
echo powerpc-linux-gnu GCC-$VERSION-$BUILD package build complete!
echo
In an earlier instance, which lasted two or three month, it was finally
admitted
that a bas file had for a short time been on the GCC svn repositiry. this file
was not eradicated during further svn updates and so stayed on my system. Given
that I intend (when load on the net is lower) to download a complete fresh copy
of gcc-4.3.0 to see if this kills the problem.
Sorry I overlooked your earlier posting the las too must have crossed each
other.
--
malitzke at metronets dot com changed:
What|Removed |Added
CC||andreast at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-06-04 22:15 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop Can anyone show that the newly added dce_loop anything useful? Yes, predictive commoning does not work as well if there is dead code (which is why it was added. Can we disable it or move it after the second reassoc? Reassoc should be fixed, we should not consider workarounds like this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #21 from hjl at lucon dot org 2007-06-04 22:19 --- (In reply to comment #20) Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop Can anyone show that the newly added dce_loop anything useful? Yes, predictive commoning does not work as well if there is dead code (which is why it was added. But predictive commoning isn't enabled at -O2, why add it for -O2? What does it give us at -O2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug middle-end/32209] Boot failure Comparing stages 2 and 3
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-04 22:01 --- So you found a bug that was only exposed with --disable-checking which usually means two thing, a gcc_assert really has side effects or something is being micompiled now. Also by the way since the trunk works without including --disable-checking, that means people are bootstrapping as required and just made a stupid mistake otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #22 from rakdver at kam dot mff dot cuni dot cz 2007-06-04 22:39 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop Can anyone show that the newly added dce_loop anything useful? Yes, predictive commoning does not work as well if there is dead code (which is why it was added. But predictive commoning isn't enabled at -O2, why add it for -O2? What does it give us at -O2? More precise view of code in loop optimizers. I cannot give any concrete example, but in principle this should not be bad and unless there are some serious reasons against it, I prefer to keep this cleanup there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-06-02 00:21:27 |2007-06-04 22:44:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #23 from dberlin at gcc dot gnu dot org 2007-06-04 23:01 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop On 4 Jun 2007 22:15:46 -, rakdver at kam dot mff dot cuni dot cz [EMAIL PROTECTED] wrote: --- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-06-04 22:15 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop Can anyone show that the newly added dce_loop anything useful? Yes, predictive commoning does not work as well if there is dead code (which is why it was added. Can we disable it or move it after the second reassoc? Reassoc should be fixed, we should not consider workarounds like this. Either fix or remove reassoc2 works for me :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #24 from rakdver at kam dot mff dot cuni dot cz 2007-06-04 23:23 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop Can anyone show that the newly added dce_loop anything useful? Yes, predictive commoning does not work as well if there is dead code (which is why it was added. Can we disable it or move it after the second reassoc? Reassoc should be fixed, we should not consider workarounds like this. Either fix or remove reassoc2 works for me :) I suppose there was some reason for having reassoc run twice? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug c/32212] New: Makefile:142: ../.././gcc/libgcc.mvars: No such file or directory
I want to build a gcc 4.3.0 fresh from svn for the fr30-elf target. Binutils 2.17 are already installed in /usr/local/fr30-elf-new/. In the gcc source directory I do: # ./configure --target=fr30-elf --prefix=/usr/local/fr30-elf-new/ [...] # make [...] The build fails with the following error message: Adding multilib support to Makefile in ../.././libgcc multidirs= with_multisubdir= make[2]: Entering directory `/mnt/space/home/tk/gcc-svn/gcc/fr30-elf/libgcc' Makefile:142: ../.././gcc/libgcc.mvars: No such file or directory make[2]: *** No rule to make target `../.././gcc/libgcc.mvars'. Stop. make[2]: Leaving directory `/mnt/space/home/tk/gcc-svn/gcc/fr30-elf/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/mnt/space/home/tk/gcc-svn/gcc' make: *** [all] Error 2 In fr30-elf/libgcc/Makefile, line 142 reads: include $(gcc_objdir)/libgcc.mvars and $(gcc_objdir) is defined in line 27 as gcc_objdir = $(MULTIBUILDTOP)../../$(host_subdir)/gcc and $(host_subdir) is defined in line 24 as host_subdir = . I found that in my build tree, the file libgcc.mvars is located in host-i686-pc-linux-gnu/gcc/libgcc.mvars So I changed line 24 of fr30-elf/libgcc/Makefile to host_subdir = host-i686-pc-linux-gnu after that, I could build without problems. I not familiar enough with autoconf and the gcc build system to hunt down that bug, so I can't offer a patch for it. Best regards, Thomas -- Summary: Makefile:142: ../.././gcc/libgcc.mvars: No such file or directory Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tk at maintech dot de GCC build triplet: host-i686-pc-linux-gnu GCC host triplet: host-i686-pc-linux-gnu GCC target triplet: fr30-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32212
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #26 from rakdver at gcc dot gnu dot org 2007-06-04 23:35 --- Created an attachment (id=13656) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13656action=view) patch preventing reassociation across loop boundaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug bootstrap/32212] Makefile:142: ../.././gcc/libgcc.mvars: No such file or directory
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 23:37 --- Building in the source directory is one of the least tested features of GCC, you should try building in a different directory as recommended by http://gcc.gnu.org/install . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32212
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #25 from rakdver at gcc dot gnu dot org 2007-06-04 23:34
---
Reassoc should be fixed, we should not consider workarounds like this.
Either fix or remove reassoc2 works for me :)
One possible fix is attached; it prevents us from reassociating across loop
boundaries. This might be too conservative, though, preventing us from
optimizing e.g.
x = ...
y = ...
while(...)
{
a = ...
b = a + x;
while (...)
c = b + y;
}
So probably this restriction should be applied only in reassoc2 (or reassoc2
should be removed, if Daniel believes it is not useful).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug other/32213] New: License for libiberty
The web page: http://gcc.gnu.org/onlinedocs/libiberty/ Indicates that libiberty is LGPL. The directory for libiberty also contain only a COPYING.LIB, again indicating it should be LGPL to me. However, at least make-relative-prefix.c indicates that it is part of libiberty, but is GPL, not LGPL. Is the license incorrect in make-relative-prefix.c, or is libiberty a mixture of multiple license types? -- Summary: License for libiberty Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mark at hatle dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32213
[Bug bootstrap/32212] Makefile:142: ../.././gcc/libgcc.mvars: No such file or directory
--- Comment #2 from tk at maintech dot de 2007-06-05 00:06 --- Ok, if I build outside the source tree, the problem doesn't appear. I'm not sure if this is still a bug or not, so I'm leaving the ticket open. Thanks for the hint! -- tk at maintech dot de changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32212
[Bug other/32213] License for libiberty
--- Comment #1 from joseph at codesourcery dot com 2007-06-05 00:07 --- Subject: Re: New: License for libiberty See http://gcc.gnu.org/ml/gcc/2003-06/msg01286.html; I don't recall seeing the SC's/FSF's answer to this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32213
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #27 from dberlin at gcc dot gnu dot org 2007-06-05 00:12 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop On 4 Jun 2007 23:35:19 -, rakdver at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #26 from rakdver at gcc dot gnu dot org 2007-06-04 23:35 --- Created an attachment (id=13656) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13656action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13656action=view) patch preventing reassociation across loop boundaries You may want to turn this on only for reassoc2. For reassoc1, we get benefit from the identities and linearization it performs, and PRE will move out what needs to be moved out. It's only the reassoc after loop opts are being performed that shouldn't be playing with calculations in loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #28 from hjl at lucon dot org 2007-06-05 00:15 --- (In reply to comment #25) So probably this restriction should be applied only in reassoc2 (or reassoc2 should be removed, if Daniel believes it is not useful). My SPEC CPU 2000 resutls in comment #18 shows reassoc2 improves some benchmarks. I will post SPEC CPU 2006 result when it finishes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug c++/32214] New: summary test
description test -- Summary: summary test Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kineiyoshida at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32214
[Bug middle-end/32209] Boot failure Comparing stages 2 and 3
--- Comment #6 from malitzke at metronets dot com 2007-06-05 01:29 --- Fantastic; My stupidity in copying the disable-checking from one of the dozen top distributors (which make experimental gcc-4.x.y available, patched them with gcc-3.x.y stuff and referred users to contact gcc maintainers directly. They stopped it recently not because I asked them to about a year ago as being counterproductive) revealed something perhaps helpful. I took the 'disable-checking out gcc-4.3.0 and it bootstrapped fine. However, grepping warning messages from three days ago and when boot failed I get the same warning messages (at least exactly the same number). I am glad no being a maintainer and having to develop a sixth sense about what side-effects or other are at work. Peace! -- malitzke at metronets dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug c++/32211] Compile error
--- Comment #1 from fang at csl dot cornell dot edu 2007-06-05 01:57 --- g++: Internal error: Killed (program cc1plus) ... suggests that some external force terminated g++. Did you perhaps run out of memory? (If so, try 'ulimit') -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32211
[Bug middle-end/32209] Boot failure Comparing stages 2 and 3
--- Comment #7 from andreast at gcc dot gnu dot org 2007-06-05 04:48 --- still broken for disable-checking -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug middle-end/32209] Boot failure Comparing stages 2 and 3
-- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-05 04:56:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
