[Bug c/27342] New: GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
./xgcc -v -save-temps -B./ -B/usr/i686-pc-linux-gnu/bin/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -L/slackw/gcc-r41/gcc.build.lnx9/gcc/../ld -O2 -O2 -O2 -pipe -fomit-frame-pointer -march=pentium3 -fno-strict-aliasing -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include -I../../gcc-4.1.1/gcc/../libcpp/include -I/usr/lib/include -I/usr/lib/include -I/l3/gmp-4.2 -DL_gcov -c libgcov.c -o libgcov.i 2>&1 |tee rmg.out xgcc: warning: -pipe ignored because -save-temps specified Reading specs from ./specs Target: i686-pc-linux-gnu Configured with: ../gcc-4.1.1/configure --prefix=/usr --enable-version-specific-runtime-libs --with-java-home=/usr --infodir=/usr/share/gcc-420 --datadir=/usr/share/gcc-420 --mandir=/usr/share/gcc-420 --program-suffix=-420 --enable-shared --enable-gomp --enable-mudflap --enable-libgfortran --enable-threads=posix --enable-__cxa_atexit --disable-checking --disable-multilib --disable-nls --disable-werror --with-gnu-ld --enable-libgcc-math --with-mpfr-dir=/l3/mpfr-2.2.0 --with-mpfr=/usr/lib --with-gmp-dir=/l3/gmp-4.2 --with-gmp=/usr/lib --enable-languages=c,c++,fortran,java,objc --with-cpu=pentium3 --enable-clocale=gnu Thread model: posix gcc version 4.1.1 20060427 (prerelease) ./cc1 -E -quiet -v -I. -I. -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include -I../../gcc-4.1.1/gcc/../libcpp/include -I/usr/lib/include -I/usr/lib/include -I/l3/gmp-4.2 -iprefix /slackw/gcc-r41/gcc.build.lnx9/gcc/../lib/gcc/i686-pc-linux-gnu/4.1.1/ -isystem ./include -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_gcov -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -isystem ./include libgcov.c -march=pentium3 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fomit-frame-pointer -fno-strict-aliasing -fPIC -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o libgcov.i ignoring nonexistent directory "/usr/i686-pc-linux-gnu/include" ignoring nonexistent directory "/usr/i686-pc-linux-gnu/sys-include" ignoring duplicate directory "./include" ignoring nonexistent directory "/slackw/gcc-r41/gcc.build.lnx9/gcc/../lib/gcc/i686-pc-linux-gnu/4.1.1/include" ignoring nonexistent directory "/slackw/gcc-r41/gcc.build.lnx9/gcc/../lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include" ignoring nonexistent directory "/usr/lib/gcc/../../i686-pc-linux-gnu/include" ignoring duplicate directory "." ignoring duplicate directory "../../gcc-4.1.1/gcc/." ignoring nonexistent directory "/usr/lib/include" ignoring nonexistent directory "/usr/lib/include" #include "..." search starts here: #include <...> search starts here: . ../../gcc-4.1.1/gcc ../../gcc-4.1.1/gcc/../include ../../gcc-4.1.1/gcc/../libcpp/include /l3/gmp-4.2 ./include /usr/local/include /usr/include End of search list. ./cc1 -fpreprocessed libgcov.i -quiet -dumpbase libgcov.c -march=pentium3 -auxbase-strip libgcov.i -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fomit-frame-pointer -fno-strict-aliasing -fPIC -o libgcov.s GNU C version 4.1.1 20060427 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20060226 (prerelease). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3c1c0ca8dc7131f4b263707b4c318e14 libgcov.c: In function 'gcov_exit': libgcov.c:161: error: 'else' label does not match edge at end of bb 140 libgcov.c:161: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets 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=27342
[Bug c/27342] GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
--- Comment #1 from malitzke at metronets dot com 2006-04-27 20:40 --- Created an attachment (id=11341) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11341&action=view) Preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27342
[Bug c/27342] GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
--- Comment #2 from malitzke at metronets dot com 2006-04-27 20:49 --- I got it once and did a svn update to 113320 for good measure but still got apparently the same segmentation fault. However, libgcov.c is processed about 14 times with a different -DLgcove_xxx each time and the error message does not specify which. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27342
[Bug c/27342] GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
--- Comment #4 from malitzke at metronets dot com 2006-04-27 21:25 --- Well, Andy, not so fast. Doing: ./xgcc -B./ -c libgcov,i I get no message and a get a "libgcov,o" Anyhow that machine is a four processor server with 2G error corrected memory. Also I have about 13 other commands processing libgcov.c, but each time with a different -DLgcov_xxx and none of them turns up any errors. -- malitzke at metronets dot com changed: What|Removed |Added Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27342
[Bug c/27342] GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
--- Comment #5 from malitzke at metronets dot com 2006-04-27 22:03 --- Further: I started the gcc-4.1.1 bootstrap with a different gcc (atually now a earlier 4.2.0) and it come up with the same "else label does not match edge." The xgcc now was generated by a different version of gcc. While this boot was going on I retried the earlier ./xgcc to most likely hit a different processor and a different memory region; same thing as before. Most likely that particular define is triggering some otherwise hidden bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27342
[Bug c/27342] GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
--- Comment #6 from malitzke at metronets dot com 2006-04-28 16:46 --- After compiling gcc-4.1.1 successfully on a powerpc and another pentium3 machine it appears that the problem reported was due to bit-rot in the server and not caught by svn updates. This appears to be confirmed by erathing the gcc-4.1.1 directory tree and transferring a new tree from the other pentium3. This passed the ./gxx cpmpile of the libgcov.c file. Therefor I am taking the liberty of marking PR27342 as fixed. -- malitzke at metronets dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27342
[Bug c/27528] New: compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
ine BUG() do { \
__asm__ __volatile__(\
"1: twi 31,0,0\n"\
".section __bug_table,\"a\"\n" \
"\t"PPC_LONG" 1b,%0,%1,%2\n" \
".previous" \
: : "i" (__LINE__), "i" (__FILE__), "i" (__FUNCTION__)); \
} while (0)
--
Summary: compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on
powerpc (7450) get error on long exixting code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug c/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #1 from malitzke at metronets dot com 2006-05-10 03:04 --- There are similar problems with other kernel modules that did not occur before. It looks like the asm expansion causes problems with some rs6000 work done by David Edelsohn. Will be glad to assist in solving this hopefully minor item. Had a Hell of a time with the known to work fail fields. There should be a way to qualify current versus twoo weeks before -- malitzke at metronets dot com changed: What|Removed |Added Known to fail||4.2.0 Known to work||3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #5 from malitzke at metronets dot com 2006-05-10 14:43 --- To A Pinski While I am _not_ a C lawyer, the following seems pertinent: 1 __FUNCTION__ is _not_ a predefined macro. However __func__ a predefined identifier and I will take this up with the kernel people. However, even changing__FUNCTION__ to __func__ still produces an error. Let the language lawyer sort this out. 2 Taking __FUNCTION__ entirely out of the original Macro Definition and using all of the kernel paraphernalia produces valid code. Out of that context I can not get even __FILE__ to work properly; only __line__ 3 Your "Hi" misses the point because it is certainly not a predefined macro and not even a predefined identifier. Therefore the comparison seems invalid to me. I am reopening this because I believe that the raised by "__func__" should be addressed. Also it is not the first time that the kernel people found ways to get GCC closer to the standards. -- malitzke at metronets dot com changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #8 from malitzke at metronets dot com 2006-05-10 20:17 --- Well Fellas: Either have the Steering Committee revise the Invitation to participate in testing; quoted iselectively below. Or,have a member from the Steering Committe ask me to refrain from further participation. I, for one, am no longer willing to be at the receiving end of snide comments from people who can not admit that, volunteering or not, are talking through their hats. I am over 70 years of age and have come to my expertise (which is not in compilers) the hard way. I started with plugboards and worked my way up to real time assembly systems programming (telephone Central Office switches and dispatching systems). The proof of any programming effort is for the hardware to generate the right output to control other hardware or to be comprehensible by human beings. Now to the specifics: > This page describes regular efforts to test GCC thoroughly, > plus ideas for additional testing by volunteers who have > machine cycles to spare. You might not believe it, but I have a router-firewall, a MAC (dual 800 Mhz G4's), a Pentium 3 server (four 550 Mhz Pentium 3 with 2Gbyte error correcting memory an 130 Giga byes of SCSI) assorted other machines all running with software entirely compiled with gcc-4.1 and gcc-4.2. I only report to gcc.gnu.org what I consider important problems. In this specific case I just eliminated the __FUNCTION__ part from bug.h (asm-powerpc) and I am writing this with kernel-2.6.17-rc3 as compiled by the current gcc-4.2 on the MAC. > Perform regular builds and testing of current GCC sources > that are not already being reported regularly. Compiling everything but Ada and running the full test suite now takes 8.5 hours on a ~800 Mhz pentium 3. There is realy no publicly available Ada source. I, personally do not care for Java, but some source packages require it and sun is apparently no coming out with new releases for the powerpc series (competition for server sales) I check the test suite output to see if that particular gcc is to be my current production compiler for either pentium3 or powerpc. > If the operating system kernel you use is normally compiled > with GCC, try building it with the current sources; > such as a release branch, use the newly built kernel for > running further GCC tests. I am a user of compilers (not only gcc) and not a compiler builder. The four or five problems I reported (and caused changes in gcc) sofar were not evidenced by the test suite. > Build and test applications that are important to you; > investigate and report any problems you find. > Build and test packages that are normally available on > your platform and for which you have access to source.a I have about 40 Gigabyte of source code (no games, no IRC, no themes or their engines, no music or downloading software, as little Java as possible, and no Pascal). This is really software for workstation use. Regarding __func__ C99 declares it a "predefined identifier" and "Like keywords, predefined identifiers must no be defined by programmers." I am not asking that it becomes part of GCC. however it should made clear that it and certainly __FUNCTION__ are no longer supported. Regarding __LINE__, __FILE__, __DATE__, etc are required as per Standard C. Again, the GCC community can state that it is no honoring that particular requiremnt. However, the GCC comunity can not unilaterally abrogate that requirement. The trigraphs come to mind. These are probably matters for the Steering Committee. -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug libgomp/26175] [4.2 Regression] In gcc-4.2.0 libgomp/.../powerpc/futex.h SYS_futex undefined
--- Comment #4 from malitzke at metronets dot com 2006-05-23 00:49 --- No need to be offensive. At the time I was using the the latest kernel available (something like 2.6.15.x or 16.x) I was still able to compile on that dual G4 MAC glibc, as available from gcc.gnu.org/pub/glibc/snapshots. Now, I cannot even get glibc to compile because the weird way glibc_pic.so is derived from glibc_pic.a because of some discarded...linkonce garbage. (see sources.redhat.com/bugzilla/.../2672) Just casting aspersions on other parts of the GNU community or the user community does not help the cause of _free_/open-source software. Richard Guenther's remark was helpful and perhaps should given more prominence in the configure documentation for both gcc and binutils regarding openmp. Example: Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: ../gcc-4.2.0/configure --prefix=/usr --enable-version-specific-runtime-libs --with-java-home=/usr --infodir=/usr/share/gcc-42 --datadir=/usr/share/gcc-42 --mandir=/usr/share/gcc-42 --program-suffix=-42 --enable-shared --enable-gomp --enable-mudflap --enable-libgfortran --enable-threads=posix --enable-__cxa_atexit --enable-libgcc-math --disable-checking --disable-multilib --disable-nls --disable-werror --with-gnu-ld --with-mpfr-dir=/src/src/mpfr-2.2.0 --with-mpfr=/usr/lib --with-gmp-dir=/src/src/gmp-4.2 --with-gmp=/usr/lib --with-cpu=7450 --enable-languages=c,c++,fortran,obj-c++,java --enable-clocale=gnu Thread model: posix gcc version 4.2.0 20060521 (experimental) BTW It is gcc that always wants to revert to __powerpc-unknown-linux-gnu__. More descriptive alternatives cause too much hassle. Also, I believe that gcc, binutils and glibc should be considered as one ball of wax and be put under one umbrella. Really, glibc is now part of the C __hosted__ specification. Also Drepper is already part of the g++ sub-empire. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26175
[Bug libgomp/26175] [4.2 Regression] In gcc-4.2.0 libgomp/.../powerpc/futex.h SYS_futex undefined
--- Comment #6 from malitzke at metronets dot com 2006-06-06 03:59 --- Good to see the GCC release manager looking at things from a user perspective, and not just looking at an individual leaf in a forest. Regarding the powerpc specific issues; I was able for just one day to compile a complete glibc package. Now, after major work on mainline binutils (the one with daily snapshots on ftp:gcc.gnu.org) It can not even pass a significant portion of its own testsuite (while the ix86 build does fine). After having been repeatedly told that the user community should not bother the _illustrious_ glibc developers with build problems I have refrained from contacting the binutils folks. The steering committee, wisely, has recognized that the gcc group can __not__ contnuously and exhaustively test all software changes on the __vast__ array of hardware configurations and thus has sought help from the user community. The operating principle being that ""All bugs are shallow if there are thousands of eyes looking "" (imperfect quote). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26175
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #11 from malitzke at metronets dot com 2006-06-15 03:03 --- Hans-Peter! Thanks for shedding _some_ light on this murky corner. Perhaps, the "i" constraint is now really inapropriate. First of all, a kernel header appropriately replaces __FUNCTION__ with __func__. Therefore the leftover __FUNCTION__ (probably from non GCC compilers) is not an issue. Second, __LINE__, __FILE__, and __func__ are all known to the compiler, because the compiler definitely knows what __FILE__ it is compiling and just emits the appropriate string. Same argument line pertains to the __LINE__ in the __FILE__ and the name of the __func__ (function) it is trying to compile. The whole idea is akin to an "assert". Therefore it is not up to the linker or assembler. Third, if putting __FILE__ in place of the of either __FUNCTION__ or __func__ it works fine as can be seen in the "-S option" output (e.g. file.s). Fourth, and this might be mine and others misunderstanding, I had thought that "i" really referred to the assembly file address of the string. This address, naturally is an address subject to relocation by the linker. To an _old_ assembly language programmer this appears just like a storm in a waterglass. This particular __asm construct is only used for powerpc (and perhaps ppc) It must be left as a holdover for the original AIX compiler or AIX binutils. In my bugzilla PR to kernel.org I pointed out that knowing the __FILE__ and __LINE__ is really quite sufficient and that perhaps, according to my patch to asm-powerpc/bug.h the particular item could be dropped. See bugzilla.kernel.org PR 6533. They have not taken it up as it only pertains to gcc-4.2.0 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #13 from malitzke at metronets dot com 2006-06-15 22:58 ---
Hans_Peter
Your, not mine, concern seems to be comment 3. For that you have to contact
Pinski. I saw a number os inconsitencies in his comments and after the
reception got did not want to pursue this further. My problem got solved as
follows:
Typescript
for i in `find -name 'bug.h*'` ; do grep -e '\ "i"\ ' $i && echo $i ; done
: : "i" (__LINE__), "i" (__FILE__)); \
: : "r" ((long)(x)), "i" (__LINE__),\
"i" (__FILE__));\
"i" (__LINE__ + BUG_WARNING_TRAP), \
"i" (__FILE__));\
./asm-powerpc/bug.h
: : "i" (__LINE__), "i" (__FILE__), "i" (__FUNCTION__)); \
: : "r" ((long)(x)), "i" (__LINE__),\
"i" (__FILE__), "i" (__FUNCTION__));\
"i" (__LINE__ + BUG_WARNING_TRAP), \
"i" (__FILE__), "i" (__FUNCTION__));\
./asm-powerpc/bug.h.org
"i"(__LINE__), "i" (__FILE__))
./asm-x86_64/bug.h
: : "i" (PAL_bugchk), "i"(__LINE__), "i"(__FILE__))
./asm-alpha/bug.h
: : "i" (__LINE__), "i" (__FILE__))
./asm-i386/bug.h
__asm__ __volatile__("break %0" : : "i" (BRK_BUG)); \
./asm-mips/bug.h
The pertinent patch is on file in my PR to bugzilla.kernel.org.
The problem turned up a week or so before I filed PR 27528, and after
considerable rs6000 changes made by David Edelsohn.
To me this is a matter for the GCC community to solve and not for a non
compiler expert like myself. I am just a user as defined by the steering
committee.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug c/24840] New: ICE process_assert_insertions_for, at tree-vrp.c:2807
Occurs with -O3 and -O2, but not -O1. Could be related to the only match found
in search 21021 also ICE tree-vrp. However now is on a ppc G4 and not with
glibc. Tried reproducibility on the -E output (error.i) with both complete of
original parameters and only with gcc -c {-O3, -O2, -O1} error.i. The error.i
is 87k and I could ftp it to the assigned GNU-trouble-shooter.
--
Summary: ICE process_assert_insertions_for, at tree-vrp.c:2807
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
GCC build triplet: powerpc-linux-gnu
GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24840
[Bug tree-optimization/24840] [4.1 Regression] ICE process_assert_insertions_for, at tree-vrp.c:2807
--- Comment #2 from malitzke at metronets dot com 2005-11-14 03:58 --- Subject: Re: [4.1 Regression] ICE process_assert_insertions_for, at tree-vrp.c:2807 Here is another try supposedly in plain text. The first bounced at your end while my copy came ok. Regards Ray _ Highspeed Internet and Email by: Metronets www.metronets.net -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24840
[Bug tree-optimization/24840] [4.1 Regression] ICE process_assert_insertions_for, at tree-vrp.c:2807
--- Comment #4 from malitzke at metronets dot com 2005-11-14 04:26 --- Created an attachment (id=10232) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10232&action=view) gcc-4.1.0-20051112 -E output of offending source error.c This error.i was made using the same gcc parameters as originally (changing -c to -E and modifying the -o part). I verified the error.i using the original parameters (getting same error message) and using only -O1 (getting error.o) and using -O2 or -O3 (getting same error message). If it would be helpful I can change to gcc-3.4.4 or even trying on an x86 instead of MAC dual processor G4. The same gcc-4.1.0-20051112 compiled linux kernel-2.6.14 fine (I am using it right now). I have been testing the gcc-4.1 for several snapshosts and as far as I could tell any error messages, other than this ICE, came from poor C or C++ code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24840
[Bug bootstrap/24984] New: Use of old "tail" parameters in Makefile*
The "tail" utility in its newer versions requires 'tail -c +16' instead of the previous 'tail +16c'. This older version seems to used from gcc-3.4* through gcc-4.1* Makefile.in. It affects testing against stage2. a simple test that shows this is to execute from the gcc-package root the following: for i in `find -name 'Makefile*'` ; do grep -H -e 'tail +16' $i ; done This is pretty petty stuff but cqan save some annoyance. -- Summary: Use of old "tail" parameters in Makefile* Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: minor Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: all GCC host triplet: all GCC target triplet: all http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24984
[Bug bootstrap/24984] Use of old "tail" parameters in Makefile*
--- Comment #2 from malitzke at metronets dot com 2005-11-22 06:00 --- Upon further investigation using coreutils-5.93 (using both the documentation and the compiled tail as test case) the following stands out: The interpretation adopted by support is on valid if env _POSIX2_VERSION=199209 is set. The default used by the coreutils group is valid if env _POSIX2_VERSION=200112 is set. If the GCC group has valid reason to insist on the older (1992) POSIX standard the the __solution__ to this issue might be to have a statement in the main configure file like: env _POSIX2_VERSION=199209 preceded by a comment like: # As all other GCC applicable standards refer to the period befor December 2001 we are also using the POSIX2 standard of 1992 for our use of head or tail. Claiming the coreutils group to be wrong will not solve the problem for the users of GCC. -- malitzke at metronets dot com changed: What|Removed |Added CC|sje at cup dot hp dot com | Status|RESOLVED|UNCONFIRMED GCC build triplet|all | Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24984
[Bug other/14251] Use POSIX-compatible flags for 'head' and 'tail'
--- Comment #18 from malitzke at metronets dot com 2005-11-22 06:04 --- See comments in PR 24984 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14251
[Bug fortran/25705] New: fortran goto from inner IF to outer ELSE (more complex than PR17708)
bl match_
mr 0,3
stw 0,660(31)
lwz 0,660(31)
cmpwi 7,0,0
bne 7,.L6
li 0,0
stw 0,656(31)
b .L1
.L6:
lwz 0,660(31)
cmpwi 7,0,1
bne 7,.L13
lwz 0,652(31)
cmpwi 7,0,1
bne 7,.L9
lis 9,[EMAIL PROTECTED]
lwz 0,672(31)
stw 0,[EMAIL PROTECTED](9)
lis 9,[EMAIL PROTECTED]
lwz 0,676(31)
stw 0,[EMAIL PROTECTED](9)
lis 9,[EMAIL PROTECTED]
lwz 0,680(31)
stw 0,[EMAIL PROTECTED](9)
lis 9,[EMAIL PROTECTED]
lwz 0,684(31)
stw 0,[EMAIL PROTECTED](9)
lis 9,[EMAIL PROTECTED]
lwz 0,688(31)
stw 0,[EMAIL PROTECTED](9)
lis 9,[EMAIL PROTECTED]
lwz 0,692(31)
stw 0,[EMAIL PROTECTED](9)
lis 9,[EMAIL PROTECTED]
lwz 0,696(31)
stw 0,[EMAIL PROTECTED](9)
lis 9,[EMAIL PROTECTED]
lwz 0,700(31)
stw 0,[EMAIL PROTECTED](9)
lis 9,[EMAIL PROTECTED]
lwz 0,704(31)
stw 0,[EMAIL PROTECTED](9)
b .L10
.L9:
li 0,0
stw 0,656(31)
b .L1
.L4:
nop
.L10:
lis 9,[EMAIL PROTECTED]
lwz 0,[EMAIL PROTECTED](9)
stw 0,656(31)
lis 9,[EMAIL PROTECTED]
lfs 0,[EMAIL PROTECTED](9)
stfs 0,708(31)
lis 9,[EMAIL PROTECTED]
lfs 0,[EMAIL PROTECTED](9)
stfs 0,712(31)
li 0,0
stw 0,652(31)
addi 0,31,668
addi 9,31,664
addi 11,31,668
addi 10,31,668
mr 3,0
mr 4,9
mr 5,11
mr 6,10
crxor 6,6,6
bl match_
mr 0,3
stw 0,660(31)
lwz 0,660(31)
cmpwi 7,0,2
bne 7,.L15
b .L13
.L15:
li 0,0
stw 0,656(31)
b .L1
.L13:
lwz 0,656(31)
stw 0,716(31)
.L1:
lwz 11,0(1)
lwz 0,4(11)
mtlr 0
lwz 31,-4(11)
mr 1,11
blr
.size qq_, .-qq_
.comm tensor_,1604,16
.comm couple_,776,16
.comm inform_,44,16
.comm kron_,400,16
.comm medefn_,660,16
.comm debug_,24,16
.comm terms_,1528,16
.comm consts_,40,16
.comm ovrlap_,84,16
.comm ovrint_,24,16
.comm machor_,8,16
.comm fact_,400,16
.comm ems_,28,16
.section.note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.5"
Error Message using gcc-4.1.0-20051230
In file q.f:61
105 IRHO=NU
1
In file q.f:52
GO TO 105 ! rmg questionable goto
2
Error: Label at (1) is not in the same block as the GOTO statement at (2)
Using built-in specs. (for gcc-4.1.0)
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.1-20051230/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/4.1.0-beta20051230
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.1.0-beta20051230/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.1.0-beta20051230
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.1.0-beta20051230/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.1.0-beta20051230/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.1.0-beta20051230/include/g++-v4
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--enable-languages=all
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu
Thread model: posix
gcc version 4.1.0 20051230 (prerelease)
--
Summary: fortran goto from inner IF to outer ELSE (more complex
than PR17708)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
GCC build triplet: powerpc-linux-gnu
GCC host triplet: powerpc-linux-gnu (really front-end)
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25705
[Bug fortran/25705] fortran goto from inner IF to outer ELSE (more complex than PR17708)
--- Comment #1 from malitzke at metronets dot com 2006-01-07 00:12 --- I know that this has no easy solution. However, just stating that this is an (implicitly) inadmissable case of going from one block to another is not satisfactory. Please PLEASE!!! do not make this into another case for specifications lawyers. What the using community needs are not arguments but continued use of working programs. Rewrites are OK when there are clear advantages in efficiency or less susceptibility to fraudulent use of existing code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25705
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #8 from malitzke at metronets dot com 2006-01-07 20:30 --- Not all of the underlying are just g77 features. Some like 18540/25705 are legal f90, f95, f06 code an just calling them "excremental" is unprofessional. This diminishes the 90% plus of dedicated people working on GCC. If something is clearly impoosible to continue as part of fortran then an effort to change the specs should be made. -- malitzke at metronets dot com changed: What|Removed |Added CC| |malitzke at metronets dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #11 from malitzke at metronets dot com 2006-01-08 00:33 --- Last things first: The code posted in 25705 is copyrighted 1994 and published in Computer Physics Communications; hence just modification by a third party could be legally questionable. The two academics (one in computer Science) conceivably were cogniscent of the f90 standard. Anyhow, standards sould be quoted in context, I have the Sep 2002 working draft (only abrogating f77, f90, and f95, per Annex B) which per Para 8.1.1.2 matches the quotation in comment 10. However, the 105 label precedes the first executable statement. Now, line 18 of 8.1 reads as follows: Any of these constructs may be named. If a construct is named, the name shall be the first lexical token of the first statement of the construct and the last lexical token of the construct. In fixed source form, the name preceding the construct shall be placed after character position 6. Therefore, the 105 GOTO address clearly is not inside the construct, because it immediately follows the ELSE and precedes character position 6 of the construct proper; and 8.1.1.2 does not apply. If label 105 would not precede the block, but be inside, then error message, pertaining to the inside of the block would be proper. Also, if commercial compilers would have a clear basis to issue an error message, they probably would do so and get off the hook. As I am clearly no the author the the code, I have no real position to defend. As my post 25705 makes clear legalistic arguments should be avoided. I also coded a parallel C program and used f2c on the code fragment posted. In both cases gcc-4.1.0 emitted object code without complaint. In this respect C and fortran are both block structured languages without nesting of subroutines. Therefore, if gcc-4.1.0 can handle it for C a parallel construct should do it for fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #16 from malitzke at metronets dot com 2006-01-08 10:41 --- Well I am very glad you people are offended. Imaging how you would feel I some one had called your work a piece of excrement. Excrement (with some minor variation in spelling) comes from Latin and means vernacular M in Spain, Portugal, France, Italy and S... in England, Germany, Sweden. At least per Webster excremental is the adjective pertaining to excrement. Pofessor Emerita C. Froese Fischer (Computer Science Vandebilt University) is the principal author of the MCHF Atomic Structure Package. Acoording to Google there are about 139 thousand citations and authorships to her credit. The MCHF package has about 1.5 megabytes of source code. I never met the lady as student, collaborator or otherwise. Calling her work even only by clearly erroneous association excrement is equivalent to calling GCC a piece of excrement. Happy sulking to you all! Now to the coding and standards issues. I stand corrected by Mr Pinski as to the contains issue. I took the statements regarding CONTAINS (page 116)in Fortran 90 Programmning (TMR Ellis et all) literally as just pertaining for fortran modules to get the calling parameters properly to the compiler the way header files do in C. Only much later in the book is the nesting issue broached. However Mr Pinski also jumping a (in may reckoning) to a wrong conclusion in terming my submission the short citation (a fraction of one percent, allowable under my interprtration of Copyright) of Professor Frose Fischer work as being the equivalent the one containing the "excremental" adjective. The 105 label in my submission precedes the first executable statement while the pertinent label in the ealier submission (which never turned up when I searched for various combinations of GTO and fortran) clearly comes after the first executable statement. This makes that "excremental" case a clear violation of 8.1.1.2. To Mr. Kargl I would counsel moderation is the the of the "Imperial" we and perhaps practice some more reading specifications. His interpretation of "is" and "shall be" in relation the 8.1.1.2 clearly shows his lack of experience. Last, but not least, I do not even pretend to be compiler expert, even after having fairly good understanding of the "Dragon Book". At best I am just a tester, regardles of having hacked GCC code since the late 80's to get GCC to work on SCO's 386 Xenix. I got my start with plugboard punched card equipement and worked as real-time assembly programmer. Now, I am just trying (as a retiremnt hobby) to bring code like Professor Froese Fischer's to a wider audience before it is withdrawn from public access in disgust at being belittled. If in the process I can do some further good by testing forthcoming versions of GCC so much the better. Your reactions provide further amusement. As a result of submitting aboout 10 Gigabytes of source code to GCC I have other irons in the fire for the easily offended to get burned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug c/29481] extra line in gcc/cgraphunit.c at line 1135
--- Comment #1 from malitzke at metronets dot com 2006-10-15 19:10 --- The line is actually in gcc/cgraphunit.c and not graphunit.c (sorry). cgraphunit.c was subjected to change by Jan Hubicka and Richard Guenther to fix PR middle-end/29299 on 2006-10-15. Probably something went wrong during the update of the master file. -- malitzke at metronets dot com changed: What|Removed |Added Summary|extra line in |extra line in |gcc/graphunit.c at line 1135|gcc/cgraphunit.c at line ||1135 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29481
[Bug middle-end/29481] [4.2 Regression] extra line in gcc/cgraphunit.c at line 1135
--- Comment #3 from malitzke at metronets dot com 2006-10-15 19:46 --- This shows fantastic turnaroud; even on a weekend. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29481
[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #9 from malitzke at metronets dot com 2007-04-02 20:39 --- I believe this report can be closed. I was able to find the start date (2061125) or a day later when I could no longer bootstrap. It disappeared towards the end of January 2007. It prevented bootstrapping on x86 but not on powerpc. It has not reappeared and was consistent on three x86 machines. It seems that many maintainers ar not doing the complete (and quite time consuming bootstrapping) during the non-regression period. -- malitzke at metronets dot com changed: What|Removed |Added CC||pinskia at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug libstdc++/31440] New: libstdc++-g++-v3 discarded qualifiers
Making all in Core
make[3]: Entering directory
`/var/tmp/portage/dev-lang/maude-2.1.1-r2/work/maude-2.1.1/src/Core'
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/Utility
-I../../src/Interface -I../../src/Variable -I../../src/FullCompiler -O2 -pipe
-mcpu=G4 -fomit-frame-pointer -Wno-deprecated -MT libcore_a-memoTable.o -MD -MP
-MF ".deps/libcore_a-memoTable.Tpo" \
-c -o libcore_a-memoTable.o `test -f 'memoTable.cc' || echo
'./'`memoTable.cc; \
then mv ".deps/libcore_a-memoTable.Tpo" ".deps/libcore_a-memoTable.Po";
\
else rm -f ".deps/libcore_a-memoTable.Tpo"; exit 1; \
fi
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include/g++-v3/bits/stl_tree.h: In
member function 'typename std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::iterator std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_lower_bound(const std::_Rb_tree_node<_Val>*, const
std::_Rb_tree_node<_Val>*, const _Key&) const [with _Key = DagNode*, _Val =
std::pair, _KeyOfValue =
std::_Select1st >, _Compare =
MemoTable::dagNodeLt, _Alloc = std::allocator >]':
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include/g++-v3/bits/stl_tree.h:1302:
instantiated from 'typename std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::iterator std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::find(const _Key&) [with _Key = DagNode*, _Val = std::pair, _KeyOfValue = std::_Select1st >, _Compare = MemoTable::dagNodeLt, _Alloc =
std::allocator >]'
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include/g++-v3/bits/stl_map.h:541:
instantiated from 'typename std::_Rb_tree<_Key, std::pair,
std::_Select1st >, _Compare, typename
_Alloc::rebind >::other>::iterator std::map<_Key,
_Tp, _Compare, _Alloc>::find(const _Key&) [with _Key = DagNode*, _Tp =
DagNode*, _Compare = MemoTable::dagNodeLt, _Alloc =
std::allocator >]'
memoTable.cc:76: instantiated from here
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include/g++-v3/bits/stl_tree.h:938:
error: passing 'const MemoTable::dagNodeLt' as 'this' argument of 'bool
MemoTable::dagNodeLt::operator()(const DagNode*, const DagNode*)' discards
qualifiers
make[3]: *** [libcore_a-memoTable.o] Error 1
make[3]: Leaving directory
`/var/tmp/portage/dev-lang/maude-2.1.1-r2/work/maude-2.1.1/src/Core'
Without direction I am not swift enough to characterize this further.
--
Summary: libstdc++-g++-v3 discarded qualifiers
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
GCC build triplet: powerpc-unknown-linux-gnu
GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31440
[Bug c/31541] New: cannot take address of bit field
i686-pc-linux-gnu-gcc: warning: -pipe ignored because -save-temps specified
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.0/configure
--mandir=/usr/share/i686-pc-linux-gnu/4.3.0/man
--infodir=/usr/share/i686-pc-linux-gnu/4.3.0/info --prefix=/usr
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--disable-nls --disable-checking --disable-multilib --disable-werror
--enable-shared --enable-libgcc-math --enable-tls --enable-threads=posix
--enable-bootstrap --enable-__cxa_atexit --enable-languages=c,c++,fortran
--with-cpu=pentium3 --enable-clocale=gnu
Thread model: posix
gcc version 4.3.0 20070411 (experimental)
/usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -E -quiet -v -IOBJ/x86-linux-cc
-I../incs/x86-linux-cc -I../include -I../libscg -I../cdrecord
-D__attribute_const__=const -DSCHILY_BUILD -DFIFO
-DCD_DEVICE="yourSCSI_Bus,yourSCSI_ID,yourSCSI_LUN" -DFILENAME="audio"
-DUNDERSAMPLING=1
-DVERSION="2.01.01a25_linux_2.6.20.4a_i686_pentium-iii--katmai-" -DBITS_P_S=16
-DCHANNELS=2 -DAUDIOTYPE="wav" -DDURATION=0 -DDEF_INTERFACE="generic_scsi"
-DUSE_PARANOIA=1 -DDEFAULT_SPEED=0 -DCDINDEX_SUPPORT -DCDDB_SUPPORT
-DCDDBHOST="freedb.freedb.org" -DCDDBPORT=8880 -DHAVE_IOCTL_INTERFACE
-DECHO_TO_SOUNDCARD -DSOUND_DEV="/dev/dsp" -DNSECTORS=75 -DINFOFILES
-DMD5_SIGNATURES -DAUX_DEVICE="/dev/cdrom" -DSCHILY_PRINT scsi_cdr.c
-march=pentium3 -finput-charset=ISO-8859-1 -fexec-charset=UTF-8 -O -O2
-fpch-preprocess -o scsi_cdr.i
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
OBJ/x86-linux-cc
../incs/x86-linux-cc
../include
../libscg
../cdrecord
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include
/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed
/usr/include
End of search list.
/usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -fpreprocessed scsi_cdr.i -quiet
-dumpbase scsi_cdr.c -march=pentium3 -auxbase-strip OBJ/x86-linux-cc/scsi_cdr.o
-O -O2 -version -finput-charset=ISO-8859-1 -fexec-charset=UTF-8 -o scsi_cdr.s
GNU C version 4.3.0 20070411 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.3.0 20070411 (experimental).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bf863a5feb01e9874cf4d63968228528
scsi_cdr.c: In function 'select_secsize':
scsi_cdr.c:2063: error: cannot take address of bit-field 'sense_data_len'
scsi_cdr.c:2063: error: cannot take address of bit-field 'sense_data_len'
scsi_cdr.c:2063: error: cannot take address of bit-field 'sense_data_len'
This is from cdr-tools-2.01.01_alpha255. It compiled OK with the gcc-4.2.0
branch. I had a hard time getting Schily's nested makefiles to give me a
required scs_cdr.i output. My attempts at reducing were fruitless.
--
Summary: cannot take address of bit field
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
GCC build triplet: i686-pc-linux-gcc
GCC host triplet: i686-pc-linux-gcc
GCC target triplet: i686-pc-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug c/31541] cannot take address of bit field
--- Comment #1 from malitzke at metronets dot com 2007-04-11 21:25 --- Created an attachment (id=13352) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13352&action=view) required "i" file Unreduced, as a user of gcc I am not up to the task -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug libstdc++/31779] New: GLIBCXX_3.4.9 undefined in libstdc++.so.6 (link time)
One more potential conspiracy item against gcc-4.2.0.
The following three items were obtained on three different machines sporting
late gcc-4.2.0
versions. (less than one week old)
cmake: relocation error: cmake: symbol _ZNSo9_M_insertEPKci, version
GLIBCXX_3.4.9 not defined in file libstdc++.so.6 with link time reference
./cmake: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: no version
information available (required by ./cmake)
./cmake: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: no version
information available (required by ./cmake)
./cmake: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: no version
information available (required by ./cmake)
./cmake: relocation error: ./cmake: symbol
_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i,
version GLIBCXX_3.4.9 not defined in file libstdc++.so.6 with link time
reference
cmake: /usr/lib/gcc/powerpc-unknown-linux-gnu/4.1.2/libstdc++.so.6: version
`GLIBCXX_3.4.9' not found (required by cmake)
The first two come from pentium3's the last from a powerpc
I did a search agains GLIBCXX and turned up four items seemingly unrelated like
GLIBCXX-DEBUG.
Besides cmake there were similar messages relating tho wxGTK re2c and others.
These messages went away when doing a bootstrap to gcc-4.3.0 and recompiling
the offending programs.
Doing a "grep -r -e '3\.4\.9' *" in gcc-4.2.0 libstdc++-v3 did nor help me;
while in gcc-4.3.0
did not help me in identifying with gcc-4.3.0 things seem to work.
I certainly would not know how to produce a relevant preprocessed xxx.i.
Willing to help but require instructions.
--
Summary: GLIBCXX_3.4.9 undefined in libstdc++.so.6 (link time)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
GCC build triplet: same
GCC host triplet: i868-pc-linux-gnu: powerpc-unknown-linux-gnu
GCC target triplet: same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31779
[Bug libstdc++/31779] GLIBCXX_3.4.9 undefined in libstdc++.so.6 (link time)
--- Comment #4 from malitzke at metronets dot com 2007-05-02 00:20 --- I accept that there is something wrong on my side. Be it "forward" or "backward". However, there are some things that I still do not understand. Cmake was compiled several times with different bootstrapped gcc-4.2.0 and it should have picked the appropriate libstdc++.so.6. More to the point is the situation with glibc (cvs) which for some time was only compilable with gcc-3.4.6 and only recently turned compilable (with some trickery) with gcc-4.1.1(2). Glibc fails abysmally with gcc-4.3.0 but the older glibc compilations do work with with gcc-4.3.0. compiled programs. It seems that some programs have a mechanism to discriminate on library versions while others do not. Also some makefiles seem to require libraries in /usr/lib while other are quite happy with the libraries in /usr/lib/gcc/ It seems to be a case of user beware and I will have to do more compilations and carefully erase what is not strictly appropriate. Anyhow, thanks for the info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31779
[Bug c/31990] New: udivdi3 not found for linux kernel
I just filed (verbatim) the PR reproduced below with bugzilla.kernel.org (8501)
Hopefully the exports will be able to communicate directly.
Most recent __gcc__ compiler where this bug did *NOT* occur: gcc-4.2.0
Distribution:
Hardware Environment: x86 (will try on MAC G4 machine)
Software Environment: gcc compilers
Problem Description: "make V=1" output
kernel/built-in.o: In function `getnstimeofday':
(.text+0x1e48d): undefined reference to `__udivdi3'
kernel/built-in.o: In function `do_gettimeofday':
(.text+0x1e5b5): undefined reference to `__udivdi3'
kernel/built-in.o: In function `update_wall_time':
--
Summary: udivdi3 not found for linux kernel
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #2 from malitzke at metronets dot com 2007-05-18 18:57 --- Andy there you go again: Irrelevancies and make work for others. You folks at gcc made tons of changes in gcc-4.3 regarding machine definitions and similar. I have some evidence that some blatant mistakes were silently corrected without mentioning even ICE's in gcc bootstrap. I refrained (wisely) from saying anything about compilations using 3Gigs of memory and then collapsing,. Now an insider has come to acknowledge that problem,PR31863. How about your patch to overcome the PR 31541 (bit field addressing) now untouched for almost one month. It is no wonder that a lot of packages, when I tell them about easy fixes regarding gcc-4.x.y, reply "we rather deal deal with gcc-3.x.y or even gcc-2.x( even with -fno-strength-reduce). The gcc group really working hard at overcoming problems noticed by users are the gfortran people (Yes, I had my run-in with them over the goto thing, but they have not caused me to file any PR's after that) Now to some perhaps ppoorly understood by my self technical issues: 1. binutils does a MACRO regarding udevdi3, but its is impossible to build binutils (even current CVS with gcc-4.3.0) 2. gcc-4.2.1 compiles the impacted kernel fine. To my simple, but seasoned, mind the onus when something stops working is on the party that made changes (namley gcc going from 4.2 to 4.3); not on the one that did not change in this case kernel-2.6.20.11. 3. I referred to to the experts in both organizations and I do not believe that you are the gcc expert in machine descriptions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #4 from malitzke at metronets dot com 2007-05-18 21:11 --- Andy! Taking your your advice to calm down I looked for the built-in.c file you wanted preprocessed. Well, it does not exist as built-in.o is a composite object file. The Kernel peoople being a more helpful and b) having more expertise asked for time.s and timekeeping.s out out time.c and timekeeping.c. I attached already both to PR8501. and you can take it from there. -- malitzke at metronets dot com changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #6 from malitzke at metronets dot com 2007-05-18 22:58 --- Created an attachment (id=13580) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13580&action=view) time.i form ./kernel/time.c first requested attachment -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #7 from malitzke at metronets dot com 2007-05-18 23:10 --- Created an attachment (id=13581) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13581&action=view) timekeeping.i from ./kernel/time/timekeeping.c Second requested attachemnt. Observation: You might just as well close on the basis of your last paragraph. This is really a documentation issue in getting the info to people like kernel.org and others writing programs for free-standing or embedded systems. There are already udivdi3 equivalents in the kernel-tree for a number of architectures. Maybe you can forward this to the right peopl;e within gcc or tell me who to contact. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #9 from malitzke at metronets dot com 2007-05-18 23:45 --- Mr Pinski I give up. I hereby formally request that you, Mr. Pinksi, refrain from having anything to do with problem reports originating from myself (Rainer Malitzke-Goes alias Ray Malitzke). I rather see them languishing unattended than having to deal with you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #11 from malitzke at metronets dot com 2007-05-19 02:02 --- Well, this is getting funny. You and apparently others at gcc are looking at the computer-sofware world through a high powered telescope and in this drastically reduced field of vision you-all only see gcc. I refreshed my memory and the linux-kernel admits other compilers besides gcc, specifically for the arm hardware. It so happens that I started with UNIX using the Seventh Edition (late seventies) By the time of the Seventh Edition everything in Unix depended on the Ritchie assembler and the Ritchie C compiler. With the Intel i386 and the Compaq 386 I migrated to the SCO Xenix (an amalgamation of the AT&T kernel and AT&T UNIX utilities utilities plus some BSD stuff like vi and an absolutely lousy Microsoft C compiler. Even so I managed to migrate with this compiler to the Public Domain Korn Shell (pdksh). In order to get to bash I had to hack gcc to produce xout object code (really *.s files) as the libraries were all in that xout format and to port the BSD libraries was too much work for one person. Therfore I learnt to patch gcc., and got bash as a result. I also played with the GNU utilities, but the original Unix ulities were quite adequate. This cozy little world collapsed when gcc underwent a complete rewite from gcc-2.58 to gcc-2.60 (no patches). The salvation was in the then quite early linux kernel. But I had to hack the kernel to read the Xenix formatted hard drives with their hermaphroditic addressing. (the linux kernel to his day sports some drivers for Xenix SYSV and Coherent, but at least for Xenix these drivers work only on floppies. Thus I became probaly one the few persons, who hacked both gcc and linux. At the same time I made MS-DOS livable using the Canadian Mortice Kern (UNIX emulation) package. I cheerfully admit to some biases one of which is that outstanding programmers like Ritchie, Torvalds, Stallmann were also accomplished assembly language programmers and that C is really a high level and portable assembly language. I really do not like all the stuff piled on top of the good old C. In the end, some of the stuff I hear about things like libgcc just make me smile. I have to say that me writing this brought me some joy, probaly much more than it has for somebody reading this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug c/32044] New: udivdi3 counterproductive, unwarranted use
First I am herewith re-afirming my formal request for Mr. Pinsk to refrain from
having anything to do with my submissions.
Now to the heart of the matter:
According to my (admittedly second hand (Fifth Edition of "C A Reference
Manual"
by Samuel P. Harbison III & Guy L. Stelle Jr) reading; GCC, by not providing a
means to disable the use of libgcc (including udivdi3) is not in strict
conformance with the C standard for free-standing use through C99. __udivdi3 is
a reserved identifier
and hence non-conforming.
The irony is that, besides, being non-conforming and prejudicing free standing
applications that aim for maximum portability, it is highly counterproductive
in its own right.
Also, the forced and silent use of libgcc (lld does not show it being used)
violates one of the fundamental principles of both UNIX and C. Namely that
the user (certainly root) is to be in full and absolute command of the system
without hidden reinterpretation of his commands or MS type questions. As a
practical matter the use of __builtin_expect could be taken as signal to
allow only reordering of instructions (to avoid pipeline stalls and
reloading of caches) are to be avoided in the marked unlikely cases. Any
fundamental changes like exchanging a while and a subtraction for a
non-hardware
divide should no occur
If anybody at GCC wants to know what others (including L. Torvalds and A.
Morton) think; checking Google on udivdi3 might be instructive.
What follows are the result of tests using current versions of gcc-4.3 and
4.2.1.
I believe the results speak for themselves. Besides the data for x86 I also
have quite similar data for powerpc G4, which I will make available as a
follow on.
Program
#define NSEC_PER_SEC 10UL
int rmg(void);
int main(void)
{
/* int sec; */
return rmg();
}
int rmg(void)
{
static unsigned long long nsec = 0;
static int sec = 0;
while (sec < 1 ) {
nsec++;
while (__builtin_expect(nsec >= NSEC_PER_SEC, 0)) {
nsec -= NSEC_PER_SEC;
++sec;
}
}
return sec;
}
gcc_43 -O0
-rwxr-xr-x 1 root root 8478 2007-05-22 08:23 rmgg_O0
-rw-r--r-- 1 root root 1238 2007-05-22 08:18 rmgg_O0.s
real0m27.613s
user0m27.607s
sys 0m0.003s
gcc_43 -O1
-rwxr-xr-x 1 root root 12586 2007-05-22 08:25 rmgg_O1
-rw-r--r-- 1 root root 1572 2007-05-22 08:25 rmgg_O1.s
real0m12.776s
user0m12.775s
sys 0m0.003s
gcc_43 -O2
-rwxr-xr-x 1 root root 12586 2007-05-22 08:27 rmgg_O2
-rw-r--r-- 1 root root 1874 2007-05-22 08:27 rmgg_O2.s
real0m16.415s
user0m16.414s
sys 0m0.004s
gcc_43 -Os
-rwxr-xr-x 1 root root 12586 2007-05-22 08:29 rmgg_Os
-rw-r--r-- 1 root root 1925 2007-05-22 08:29 rmgg_Os.s
real2m8.817s
user2m8.831s
sys 0m0.003s
Program
#define NSEC_PER_SEC 10UL
int rmg(void);
int main(void)
{
/* int sec; */
return rmg();
}
int rmg(void)
{
static unsigned long long nsec = 0;
static int sec = 0;
while (sec < 1 ) {
nsec++;
while (__builtin_expect(nsec >= NSEC_PER_SEC, 0)) {
nsec -= NSEC_PER_SEC;
++sec;
}
}
return sec;
}
gcc_42 -O0
-rwxr-xr-x 1 root root 8471 2007-05-21 16:46 rmgg_O0
-rw-r--r-- 1 root root 1236 2007-05-21 16:41 rmgg_O0.s
time ./rmgg_O0
real0m27.678s
user0m27.680s
sys 0m0.002s
Script done on Mon 21 May 2007 04:53:29 PM EDT
gcc_42 -O1
-rwxr-xr-x 1 root root 8471 2007-05-21 16:41 rmgg_O1
-rw-r--r-- 1 root root 1572 2007-05-22 09:39 rmgg_O1.s
Script started on Mon 21 May 2007 04:56:20 PM EDT
time ./rmgg_O1
real0m12.771s
user0m12.767s
sys 0m0.003s
Script done on Mon 21 May 2007 04:56:55 PM EDT
gcc_42 -O2
-rwxr-xr-x 1 root root 8471 2007-05-21 16:41 rmgg_O2
-rw-r--r-- 1 root root 1262 2007-05-21 17:41 rmgg_O2.s
Script started on Mon 21 May 2007 04:57:14 PM EDT
time ./rmgg_O2
real0m12.532s
user0m12.531s
sys 0m0.003s
Script done on Mon 21 May 2007 04:58:18 PM EDT
gcc -Os
-rwxr-xr-x 1 root root 8471 2007-05-21 16:41 rmgg_Os
-rw-r--r-- 1 root root 1017 2007-05-21 16:40 rmgg_Os.s
Script started on Mon 21 May 2007 04:58:30 PM EDT
time ./rmgg_O2
real0m12.571s
user0m12.562s
sys 0m0.004s
Script done on Mon 21 May 2007 04:59:11 PM EDT
--
Summary: udivdi3 counterproductive, unwarranted use
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets 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=32044
[Bug c/32044] udivdi3 counterproductive, unwarranted use
--- Comment #1 from malitzke at metronets dot com 2007-05-22 17:27 --- Created an attachment (id=13601) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13601&action=view) *.s files I believe that the *.s files in this case a superior to the *.i files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug c/32044] udivdi3 counterproductive, unwarranted use
--- Comment #2 from malitzke at metronets dot com 2007-05-22 17:37 --- Created an attachment (id=13602) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13602&action=view) *.s files for gcc-4.2 *.s files generated by gcc-4.2.1 as more responsive to the intent and superior in performance according to the selected option. -march=pentium3 make no difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #6 from malitzke at metronets dot com 2007-05-23 01:06 --- I did try changing #define 10Ul to its rightful hexadecimal value #define 0x3b9aca00UL. the results are: .file "rmgg.c" .globl __udivdi3 .text .p2align 4,,15 .globl rmg .type rmg, @function rmg: pushl %ebp movl%esp, %ebp pushl %edi movl$-10, %edi pushl %ebx subl$48, %esp movlnsec.1646, %eax movlnsec.1646+4, %edx movl%eax, -16(%ebp) movlsec.1647, %eax movl%edx, -12(%ebp) testl %eax, %eax jg .L10 .p2align 4,,15 .L5: movl-16(%ebp), %edx movl-12(%ebp), %ecx addl$1, %edx adcl$0, %ecx cmpl$0, %ecx jbe .L11 .L7: addl$-10, %edx adcl$-1, %ecx incl%eax addl$-9, -16(%ebp) movl%edx, -32(%ebp) movl$10, %edx adcl$-1, -12(%ebp) movl%ecx, -28(%ebp) movl%edx, 8(%esp) movl-12(%ebp), %ecx movl-16(%ebp), %edx movl%eax, -20(%ebp) xorl%eax, %eax movl%eax, 12(%esp) movl%ecx, 4(%esp) movl%edx, (%esp) call__udivdi3 imull $-10, %edx, %ecx movl%eax, %ebx subl%eax, %ecx mull%edi addl%ecx, %edx movl%eax, -40(%ebp) movl-20(%ebp), %eax movl%edx, -36(%ebp) movl-40(%ebp), %edx addl-32(%ebp), %edx movl-36(%ebp), %ecx adcl-28(%ebp), %ecx addl%ebx, %eax movl%edx, -16(%ebp) movl%ecx, -12(%ebp) .p2align 4,,15 .L12: testl %eax, %eax jle .L5 .L10: movl-16(%ebp), %edx movl-12(%ebp), %ecx movl%eax, sec.1647 movl%edx, nsec.1646 movl%ecx, nsec.1646+4 addl$48, %esp popl%ebx popl%edi popl%ebp ret .p2align 4,,7 .L11: cmpl$9, %edx ja .L7 movl%edx, -16(%ebp) movl%ecx, -12(%ebp) jmp .L12 .size rmg, .-rmg .p2align 4,,15 .globl main .type main, @function main: leal4(%esp), %ecx andl$-16, %esp pushl -4(%ecx) pushl %ebp movl%esp, %ebp pushl %ecx subl$4, %esp callrmg popl%ecx popl%ecx popl%ebp leal-4(%ecx), %esp ret .size main, .-main .local sec.1647 .comm sec.1647,4,4 .local nsec.1646 .comm nsec.1646,8,8 .ident "GCC: (GNU) 4.3.0 20070522 (experimental)" .section.note.GNU-stack,"",@progbits I will try both Mr. Taylor volatile suggestion and if I can retrieve Mr Park's proposed patch in ascii I will try that one too Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #7 from malitzke at metronets dot com 2007-05-23 02:09 --- Thank you Mr Taylor; your suggestion to use volatile certainly work in this drastically reduced test case. If it will work when nsec is part of a kernel structure I will leave to the experts. I, certainly, know better than to argue with you, who wrote uucp and has been active on gcc for probably 15 years or more. The *.s file and the results of time follow: (both obtained with -O1) .file "rmgg.c" .text .p2align 4,,15 .globl rmg .type rmg, @function rmg: movlsec.1647, %ecx pushl %ebp movl%esp, %ebp testl %ecx, %ecx jg .L18 .L6: movlnsec.1646, %eax movlnsec.1646+4, %edx addl$1, %eax adcl$0, %edx movl%eax, nsec.1646 movl%edx, nsec.1646+4 movlnsec.1646, %eax movlnsec.1646+4, %edx cmpl$0, %edx jbe .L15 .L13: movlnsec.1646, %eax movlnsec.1646+4, %edx addl$-10, %eax adcl$-1, %edx incl%ecx movl%eax, nsec.1646 movl%edx, nsec.1646+4 movlnsec.1646, %eax movlnsec.1646+4, %edx cmpl$0, %edx ja .L13 .p2align 4,,15 .L15: cmpl$9, %eax ja .L13 testl %ecx, %ecx jle .L6 .L18: popl%ebp movl%ecx, %eax movl%ecx, sec.1647 ret .size rmg, .-rmg .p2align 4,,15 .globl main .type main, @function main: leal4(%esp), %ecx andl$-16, %esp pushl -4(%ecx) pushl %ebp movl%esp, %ebp pushl %ecx callrmg popl%ecx popl%ebp leal-4(%ecx), %esp ret .size main, .-main .local sec.1647 .comm sec.1647,4,4 .local nsec.1646 .comm nsec.1646,8,8 .ident "GCC: (GNU) 4.3.0 20070522 (experimental)" .section.note.GNU-stack,"",@progbits real0m16.433s user0m16.425s sys 0m0.004s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #10 from malitzke at metronets dot com 2007-05-23 13:17 --- Mr. Guenther! The volatile fix would be fine, but (at least for me) does not work with the kernel. There is that little message: kernel/time.c:479: warning: passing argument 3 of 'div_long_rem_signed' discards qualifiers from pointer target type. and others like it, and, udivdi3 reappears. Mr. Park! The patch you kindly included in comment 3 presented two difficulties: 1. I Acould not extricate it cleanly enough from the html encoding apparently standard with bugzilla. (this is a Mozilla Product) 2. After some editing patch just accepted 1 hunk and upon checking it turned out that the svn derived tree-scalar.evolution.c did not match the enclosing lines around the lines to be added. I added those lines by hand (possibly imperfectly, enven on careful checking) the file compiled OK, but, runnign the gcc check sequence I got a stream of error. These errors disappeared on using a sequestered unpatched copy of the file. Hence, udivdi3 reappeared. If you see fit for me to test this not only on the reduced test case but on the actual kernel I suggest sending me a updated patch as a text attachment to my email. Thanks to all for trying to help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #11 from malitzke at metronets dot com 2007-05-23 14:51 --- Mr. Ibanez! Thank you (muchas gracias) for looking at the matter from a user's point of view and considering my arguments concerning __builtin_expect. You seem to be the first to look at the timings and amount of code generated. If you are interested I have equivalent data taken on a MAC with dual G4's. I did not send it so far because until you intervened I got mostly legalistic arguments and proposed fixes that do no solve the real problem of avoiding both udivdi3 and more importantly libgcc. -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #13 from malitzke at metronets dot com 2007-05-24 14:08 --- Mr Guenther! Thank you (herzlichen Dank) for the information about the hopefully disabling flag. If that information would have been posted after my initial intervention we could have saved a lot of bandwidth and storage space. I realize libgcc is one of the areas you are responsible for and libgcc definitely fills a need for a hosted implementation. Also, (at least for me) the optimization is strictly an internal matter for the gcc community and I have nothing to contribute in this regard. To sum up; as a user, and, in the UNIX spirit (I started with the 7th edition), I just want freedom in choosing the facilities and features gcc has to offer. I hope that this or similar flags provide me with the capability to banish libgcc and similar facilities from my programs under the C free-standing specification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[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 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 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 2>&1 | 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 2>&1 |tee .Build
# LIBPATH=/$TARGET/$VERSION bootstrap 2>&1 |tee -a .Build
make install DESTDIR=/$TMP/destdir-$BUILD 2>&1 | tee .Inst
nice --adjustment=18 make -j2 -i check 2>&1 |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 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 middle-end/32209] Boot failure Comparing stages 2 and 3
--- Comment #9 from malitzke at metronets dot com 2007-06-05 13:44 --- Mr. Tobler Thanks for pursuing this. For me. as a user, it is solved. My analysis, as an outsider, points to the corruption, inadvertent chang, update malfunction of an include file shared by the *.c files leading to the *.o files. Looking for the 1...n level include files might give a clue. If you think I could be helpful do not hesitate to ask. Cheers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug c/32314] New: for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
disable-decimal-float not working on i686, powerpc, sparc neither gcc-4.2.1 nor
gcc-4.3.0
Proof; below is a compossite from directory libdecnumber(top of config.status
and ls -l)
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by cpplib configure , which was
generated by GNU Autoconf 2.59. Invocation command line was
$ /var/tmp/gcc_r43/gcc-4.3.0/libcpp/configure --cache-file=./config.cache
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-nls
--disable-multilib --disable-werror --disable-libunwind-exceptions
--disable-checking --disable-decimal-float --enable-shared --enable-tls
--enable-threads=posix --enable-bootstrap --enable-__cxa_atexit
--enable-clocale=gnu --with-cpu=pentium3 --with-system-zlib
--enable-languages=c,c++,fortran --program-transform-name=s,y,y,
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
--srcdir=../../gcc-4.3.0/libcpp --with-build-libsubdir=.
## - ##
## Platform. ##
## - ##
..
total 620
-rw-r--r-- 1 root root 7902 2007-06-12 18:40 Makefile
-rw-r--r-- 1 root root 18924 2007-06-12 18:40 charset.o
-rw-r--r-- 1 root root 7826 2007-06-12 18:40 config.cache
-rw-r--r-- 1 root root 8674 2007-06-12 18:40 config.h
-rw-r--r-- 1 root root 77880 2007-06-12 18:40 config.log
-rwxr-xr-x 1 root root 44155 2007-06-12 18:40 config.status
-rw-r--r-- 1 root root 21976 2007-06-12 18:40 directives.o
-rw-r--r-- 1 root root 2976 2007-06-12 18:40 errors.o
-rw-r--r-- 1 root root 17068 2007-06-12 18:40 expr.o
-rw-r--r-- 1 root root 14284 2007-06-12 18:40 files.o
-rw-r--r-- 1 root root 2216 2007-06-12 18:40 identifiers.o
-rw-r--r-- 1 root root 6364 2007-06-12 18:40 init.o
-rw-r--r-- 1 root root 17848 2007-06-12 18:40 lex.o
-rw-r--r-- 1 root root 152672 2007-06-12 18:40 libcpp.a
-rw-r--r-- 1 root root 3472 2007-06-12 18:40 line-map.o
-rw-r--r-- 1 root root 38 2007-06-12 18:40 localedir.h
-rw-r--r-- 1 root root 10 2007-06-12 18:40 localedir.hs
-rw-r--r-- 1 root root 17048 2007-06-12 18:40 macro.o
-rwxr-xr-x 1 root root 130464 2007-06-12 18:40 makedepend
-rw-r--r-- 1 root root 3848 2007-06-12 18:40 makedepend.o
-rw-r--r-- 1 root root 4652 2007-06-12 18:40 mkdeps.o
-rw-r--r-- 1 root root 7448 2007-06-12 18:40 pch.o
-rw-r--r-- 1 root root 10 2007-06-12 18:40 stamp-h1
-rw-r--r-- 1 root root 3980 2007-06-12 18:40 symtab.o
-rw-r--r-- 1 root root 9948 2007-06-12 18:40 traditional.o
What follows is __not__ directed against Mr. Cowlishaw; as he did a very
workman-like programming job.
It is directed against people within the gcc community who jointly perpetrated
a bad joke on the C language. If they insist on mixing C and decimal
arithmetic; plus adding insult to injury by making the disable not work; I
would suggest adding a new language to the GNU Compiler Collection as follows:
PL1-C or Cobol-ng.
Disclosure: I have a "Certificate in Data Processing". I got it about 35 years
ago while doing real-time assembly language body-shopping for a
"Beltway-Bandit" type outfit. I learned COBOL From the COBOL chapter in Jean E.
Sammet's excellent book Book "Programming Languages: History and Fundamentals.
Enough Said"
--
Summary: for gcc-4.2gcc-4disable-decimal-float not working on
i686, powerpc, sparc. gcc-4.3.0
Product: gcc
Version: 4.2.1
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-linux-gnugcc-4disable-decimal-float not working
on i686,
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
-- malitzke at metronets dot com changed: What|Removed |Added CC||pluto at agmk dot net Severity|normal |blocker Known to work||4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #3 from malitzke at metronets dot com 2007-06-13 06:06 --- Maybe some people should read __carefully__ both the C standard and the new GPL3 -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #5 from malitzke at metronets dot com 2007-06-13 07:09 --- All I want for gcc is that it meets both the letter __and__ the spirit of applicable contracts and specifications. First, the GPL is a contract, do __not__ take my word for it but consult a lawyer. Second, the C standard can be and should be made part of a contract like a chip manufacturer would sign with a major purchaser like Ford or GM for embedded chips and the included support software like gcc. After working 80 hours with paid overtime) as a highly regarded real-time assembly programmer (before C became available) I tripled my income (no paid overtime) as an international telecommunications consultant (really RFP writer, contract negotiator, acceptance tester), project engineer, co-writer of ITU (International Telecommunications Union) specifications, and US-representative on technical supervisory committees. I caused significant economic harm to contractors (benefiting my employer or organizations I consulted for) by incorporating ITU standards in contracts. Therefore I have some knowledge of these matters. Three; gcc-4.3.0 and gcc-4.2.2 will most likely be released under the GPL3 (which not only is intended to replace GPL2 but also the lesser GPL for libraries) Four: under the C specification compiler writers can furnish extensions. But, these extensions are required to have disablers. Five: Yes, gcc is furnished by gnu.org mithout any warranty, or even being fit for merchantability. However, __hidden__ items like libgcc might constitute borderline cases. In the hands of a skillful lawyer, like Mr Edwards, these hidden items could cause a lot of grief to gnu.org and the maintainers as a group. Microsoft could even file an amicus curieae brief. -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug c/32347] New: ICE on gcc/testsuite/gcc-dg/vmx/ops.c
Reading specs from /var/tmp/gcc_r43/build-25/gcc/specs
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --host=powerpc-unknown-linux-gnu
--build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix
--enable-shared --enable-clocale=gnu --enable-bootstrap
--enable-languages=c,c++,fortran --disable-altivec --disable-checking
--disable-nls --disable-decimal-float --disable-werror --disable-multilib
--with-ibmlongdouble --with-cpu=7450 --enable-clocale=gnu --with-system-zlib
Thread model: posix
gcc version 4.3.0 20070614 (experimental)
/var/tmp/gcc_r43/build-25/gcc/cc1 -E -quiet -v -iprefix
/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/
-isystem /var/tmp/gcc_r43/build-25/gcc/include -isystem
/var/tmp/gcc_r43/build-25/gcc/include-fixed -D__unix__ -D__gnu_linux__
-D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix
-Asystem=posix ops.c -maltivec -mabi=altivec -mcpu=7450 -std=gnu99
-fno-show-column -Os -fpch-preprocess -o ops.i
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed"
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include"
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed"
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/libffi
/var/tmp/gcc_r43/build-25/gcc/include
/var/tmp/gcc_r43/build-25/gcc/include-fixed
/usr/local/include
/usr/include
End of search list.
/var/tmp/gcc_r43/build-25/gcc/cc1 -fpreprocessed ops.i -quiet -dumpbase ops.c
-maltivec -mabi=altivec -mcpu=7450 -auxbase-strip ops.s -Os -std=gnu99 -version
-fno-show-column -o ops.s
GNU C version 4.3.0 20070614 (experimental) (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070614 (experimental), GMP version
4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96544
Compiler executable checksum: 8c94e74aa22d7e7d522ab31740502ad9
ops.c: In function 'f6':
ops.c:761: error: insn does not satisfy its constraints:
(insn 1187 1186 32 2 ops.c:663 (set (reg:V4SI 78 1)
(mem:V4SI (plus:SI (reg:SI 11 11)
(const_int 16 [0x10])) [7 S16 A128])) 515 {altivec_lvx_v4si}
(nil))
ops.c:761: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE on gcc/testsuite/gcc-dg/vmx/ops.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
GCC build triplet: powerpc-unknown-linux-gnu
GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug c/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #1 from malitzke at metronets dot com 2007-06-14 19:30 --- Created an attachment (id=13704) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13704&action=view) standard preprocessed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #5 from malitzke at metronets dot com 2007-06-14 21:42 ---
Smart comment, unfortunately it is wrong. I spotted this myself and quickly
rebootstrapped gcc the results are:
Reading specs from /var/tmp/gcc_r43/build-26/gcc/specs
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --host=powerpc-unknown-linux-gnu
--build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix
--enable-shared --enable-clocale=gnu --enable-bootstrap
--enable-languages=c,c++,fortran --enable-altivec --disable-checking
--disable-nls --disable-decimal-float --disable-werror --disable-multilib
--with-ibmlongdouble --with-cpu=7450 --enable-clocale=gnu --with-system-zlib
Thread model: posix
gcc version 4.3.0 20070614 (experimental)
/var/tmp/gcc_r43/build-26/gcc/cc1 -E -quiet -v -iprefix
/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/
-isystem /var/tmp/gcc_r43/build-26/gcc/include -isystem
/var/tmp/gcc_r43/build-26/gcc/include-fixed -D__unix__ -D__gnu_linux__
-D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix
-Asystem=posix ops.c -maltivec -mabi=altivec -mcpu=7450 -std=gnu99
-fno-show-column -Os -fpch-preprocess -o ops.i
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed"
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include"
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed"
ignoring nonexistent directory
"/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/libffi
/var/tmp/gcc_r43/build-26/gcc/include
/var/tmp/gcc_r43/build-26/gcc/include-fixed
/usr/local/include
/usr/include
End of search list.
/var/tmp/gcc_r43/build-26/gcc/cc1 -fpreprocessed ops.i -quiet -dumpbase ops.c
-maltivec -mabi=altivec -mcpu=7450 -auxbase-strip ops.s -Os -std=gnu99 -version
-fno-show-column -o ops.s
GNU C version 4.3.0 20070614 (experimental) (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070614 (experimental), GMP version
4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96544
Compiler executable checksum: e4f92d229bfbaed546370fd132d96102
ops.c: In function 'f6':
ops.c:761: error: insn does not satisfy its constraints:
(insn 1187 1186 32 2 ops.c:663 (set (reg:V4SI 78 1)
(mem:V4SI (plus:SI (reg:SI 11 11)
(const_int 16 [0x10])) [7 S16 A128])) 515 {altivec_lvx_v4si}
(nil))
ops.c:761: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
the ops.i files compare identical but I could add and waste bandwidt
--
malitzke at metronets dot com changed:
What|Removed |Added
CC||dje at watson dot ibm dot
||com, geoffk at geoffk dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #6 from malitzke at metronets dot com 2007-06-14 21:50 --- This is just a more conspicuous case as evidenced looking at the data below. The almost 2:1 worse results for the powerpc show up day after day, month after month. Powerpc G4 gcc-4.3.0-20070613 check results === g++ Summary === # of expected passes16031 # of unexpected failures10 # of expected failures 86 # of unsupported tests 108 === libmudflap Summary === # of expected passes1817 # of unexpected failures9 === libstdc++ Summary === # of expected passes # of unexpected failures1 # of unexpected successes 1 # of expected failures 42 # of unsupported tests 316 === libgomp Summary === # of expected passes1566 === gfortran Summary === # of expected passes18252 # of unexpected failures24 # of expected failures 8 # of unsupported tests 36 === gcc Summary === # of expected passes45473 # of unexpected failures5 # of unexpected successes 2 # of expected failures 138 # of untested testcases 35 # of unsupported tests 434 i686 pentium3 gcc-4.3.0-20070613 check results === libmudflap Summary === # of expected passes1821 # of unexpected failures5 === libgomp Summary === # of expected passes1566 === g++ Summary === # of expected passes16165 # of unexpected failures6 # of unexpected successes 2 # of expected failures 86 # of unsupported tests 81 === gfortran Summary === # of expected passes18308 # of unexpected failures8 # of expected failures 8 # of unsupported tests 16 === libstdc++ Summary === # of expected passes4445 # of unexpected successes 1 # of expected failures 42 # of unsupported tests 316 === gcc Summary === # of expected passes45210 # of unexpected failures1 # of unexpected successes 2 # of expected failures 135 # of untested testcases 35 # of unsupported tests 318 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #7 from malitzke at metronets dot com 2007-06-16 13:08 --- It is good to be challenged, as it forces clarification of the issues. It is also good to let some grass grow instead of just charging ahead. Putting the legal and philosophical ramifications aside and considering only the technical issues; but, in a larger context, the following seems to apply. The ICE issue in PR 32314 were a consequence of pursuing the decimal float issue, but, it helps to also consider it here. The closure is provided by the introduction of POINTER_PLUS. While this might not be ideal forum for what follows I ask for indulgence in order to put things into perspective. There are really three levels to keep in mind and they are exemplified by: 1) POINTER_PLUS 2) Altivec and SSE 3) decimal float. POINTER_PLUS is clearly an internal matter for GCC and the involved specialists. A user, like my self, has no right to question it or its merits. Parenthetically, I consider it great because it makes GCC more transparent and comprehensible. Size of the compilers, efficiency of both compiler and generated code are clearly secondary (within even generous limits). Enough said. Altivec and SSE are borderline. Personally, I would love to have control over how analysis, optimization, and code generation for a specialized instruction set and data types, not mandated the the C standard, affect the compiler I use for perhaps life threatening code. However, as a practical matter, I realize that the build machinery for gcc may make it well nigh impossible to eliminate Altivec of SSE from the areas of analysis, optimization and code generation. I also doubt that the likes of Altivec and SSE can be segregated into libraries with minimal impact on the compiler proper. As a consequence, I might have only the choice of having the compiler built for a model CPU not having altivec or SSE, and foregoing any concomitant architectural improvements; or, taking any penalties in compiler complexity and quality of generated code for data types that I have no intention of using. Decimal_float: My analysis has shown that the only readily visible difference resulting from disable-decimal-float or enable-decimal-float is the doubling in size of libgcc.a. Libgcc.so seems unaffected either way. I can only hope that the impact on compiler complexity, ad-hoc code and propensity for bugs is minimal. I hate the idea of having to use gcc versions prior to gcc-4.2.0 just to completely avoid decimal float. I will leave potential legal implications and inconsistencies resulting from using COPYING.LIB and the gcc-specific disclaimer paragraph to another posting. -- malitzke at metronets dot com changed: What|Removed |Added CC||rguenther at suse dot de, ||janis187 at us dot ibm dot ||com Severity|blocker |normal Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #11 from malitzke at metronets dot com 2007-06-17 00:14 --- Thank you Mrs Johnson for putting in (by my reckoning) an inordinate amount of hours to put some bounds on this problems. I am sure you are aware of the old adage "A stitch in time saves nine". If some developer/maintainers had examined the check results many month ago this would have been much easier to fix. This inattention to sound procedures was raised in the discussion leading to the release of gcc-4.2.0. One participant in that discussion even advocated abandoning gcc-4.2.x series altogether and we all have to thank Prof. Sikora for persevering in the case of quadratic memory consumption with a remark as follows: yup, looks like a nice bullet for 4.2.0 release. with such features 4.2 will be widely /dev/nulled. I took the liberty of making you a CC on PR 32314, as with your presentation at the 2005 GCC meeting shows that you are a proponent for decimal floating point. Your calming influence will be appreciated. Thanks again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #9 from malitzke at metronets dot com 2007-06-17 18:01 --- Thank you for your very informative post. What we have between us is really a philosophical difference. To me C is a portable assembler and my extensive review of Ritchie's writings and acceptance speech for the Turing award leads me to believe that the correct code generation under absolute control of the programmer was paramount. Even the portability issue came much later at Bell Labs. That was when to my reckoning Ritche handed over C to the PCC (portable C compiler) crowd using LEX YACC etc. Yes, to me there is profound truth in "Optimize, don't". Instead look for a better algorithm. And, as as an engineer a soldering iron and a screwdriver (a better CPU and support chips like the Cell processor) are among the best optimization tools. FORTRAN was actually my first high level language and my first significant FORTRAN (formula translation) ran on the day President Kennedy was murdered, and the computer center closed. I worked on systems with triple computer redundancy and and majority voting. Boy, would I have loved a Ritchie type C compiler. One of my best accomplishments was cutting the interrupt line and and making that central office telephone exchange into scanning system and handle the contractual specified 95000 calls per hour instead of 67000. It lso made me the best hated guy in that development lab and led to a very profitable job change. Yes, I consider JAVA an abomination, I still harbor a remnant of respect for SUN because of the NFS (network file system). When Dr. hc. William Gates admitted that C++ set back Microsoft two years; it my made not only my day but my whole month. His genius is in motivating nerds to work 12-16 hours a day producing lousy code and not as progamer (somebody else wrote a vital part of the BASIC interpreter). C with classes is fantastic to somebody whose thesis contained a discrete event simulation package written in FORTRAN and assembly. Microsoft and Academia reduced C++ to the recent quip "When your tool is C++, the world is reduced to thumbs" (half-assed quote). K&R second program "Fahrenheit-Celsius" uses integers and not floating point. Based on that and knowing that existed no decent FORTRAN compilers on the early UNIX machines I take it that floating point was more a political necessity than a technical requirement. I would love to eliminate floating point from C and use fortran-95 for my numerical solutions of stiff partial differential equations. Now your first four paragraphs and my previous comment realy express the same thing, but from different perspective. Let me quote "great because it makes GCC more transparent and comprehensible" What I meant with this is that GCC now has one more leg built on sound principle instead of a (perheaps jumble of ad-hoc stuff. This in creases my confidence the addresses generated point to the right object. This put you as the lead guy into the same league as Diego Novillo, Sebastian Pop, Palo Carlini, Zdenek Dvorak I had the priviledge of helping in a small way. In my book this a big step up from bug-man. To system houses, chip manufacturers, gcc collegues obsessed with optimization you had to stress the speed-up. I want assurance that the code generated produces the right result, even if it makes the compiled bigger and the code generated for small arrays a tad slower. To me POINTER_PLUS affects code throughout the compiler collection and not just some instruction on some architecture. I am quite willing to write you a glowing recommendations should you think it appropriate. That we rub each other at times the wrong way is unfortunate bu no really relevant. Proof that you are doing great, from my perspective, Is that when I checked the Changelog after svn I searched and found your technical write-up, understood that this good stuff and immediately did a a bootstrap. It certainly produced no discernable degradation which is great no a new fundamental step. Altivec and SSE really produce benefits in a relatively small corner of the overal picture, They are, again in my book, part of their architectures more for competive reason than producing fundamental improvements. However changes to the config tree and to code generation to me far outweigh the benefits overall. But it seems imppossible to quarantine them. I have to admit that DFA really rubs me the wrong way for C. Finally, there exists huge, to me bloated, file called cc1. This is the C compiler and not GCC. Again I admit that I really only care about cc2 and f951, I tolerate cc1plus, and the rest have no place on my machines, I own those machines and aunder the GNU and UNIX philosophy that is up to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #10 from malitzke at metronets dot com 2007-06-17 23:29 --- Let me reiterate: I am not admitted to the bar in any USA state, nor the District of Columbia. Hence, I can not and I am not offering any legal advice. For legal advice see a lawyer admitted to the bar. Yes, I have worked extensively with lawyers preparing contracts, briefs and filings to regulatory agencies and also provided sworn depositions and know some of the jargon. Lets us start with a package, GLIBC, that I consider consistent and which gives me corresponding reassurance. First a randomly selected introductory paragraph and the the paragraph that comes close to the stated GCC exception because of the reference to the GNU Lesser General Public License. Copyright (C) 1991, 1995, 1996, 1997, 2002 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. COPYING and COPYING.LIB are in the root directory of the package, and I assume these two apply to the package as a whole. COPYING has as its title "GNU General Public License" and COPYING.LIB has as its tile "GNU Lesser General Public License". Section 6 I take as the essence of is termed the GGC-exception. But, to me it is section 13: 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. that really gives me confort and that is missing in the GCC verbiage. Now even in the directory gcc, ever since gcc-3.3.6 gcc-3.3.6_except_libgcc_c In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine (sic) executable.) gcc-3.3.6_except_libgcc_h As a special exception, if you link this library with other files, some of which are compiled with GCC, to produce an executable, this library does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. the two cited parapgraphs are not equal and they imperfectly convey some of the idea of COPYING.LIB, which should then be removed from the root directory. As each release is really a new work the exception paragraph could be removed with a simple sed script. This then would bring back the dreaded viral property as advocated by Mr. Stallman. However, when a library provides a significant unique capability, like GNU Readline, that's a horse of a different color. The Readline library implements input editing and history for interactive programs, and that's a facility not generally available elsewhere. Releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline. In conclusion, the GCC_exception paragraph needs the something like section 13 quoted above -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #12 from malitzke at metronets dot com 2007-06-18 00:06 --- Did you even read comment 9? -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug c/32387] New: back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis
Taking the exceptional backport of TPA to gcc-4.2.x I request studying the possibility of doing the same for POINTER_PLUS. -- Summary: back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32387
[Bug c/32387] back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis
--- Comment #2 from malitzke at metronets dot com 2007-06-18 02:47 --- I am not making this request lightheartedly. POINTER_PLUS was developed on a branch and went in very cleanly. I always stressed to my students that that "A good theory is a most practical thing" I just happen to to a member of Sigma Xi. from discussions surrounding the release of gcc-4.2.0 there appear to be a number of unresolved issues concerning gcc-4.2 and the release manager had serious misgivings. POINTER_PLUS just might help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32387
[Bug c/32387] back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis
--- Comment #4 from malitzke at metronets dot com 2007-06-18 02:53 --- I realize that good things do not come easy. I also believe there is over-reliance on regression among the gcc-insiders. Enhancement has a priority below trivial and I am jut requesting a study of an enhancement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32387
[Bug c/32387] back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis
--- Comment #5 from malitzke at metronets dot com 2007-06-18 03:15 --- Hey, more good news about POINTER_PLUS. It might help smoke out bugs in other parts of GCC. I hope these can be labeled as so called regressions so that people will be forced to work on them. Concerning non-regression test cases and as a by-product of my porting work I am developing a list of packages having good and excellent "make check" diagnostics. I do not consider kernels good test beds for a compiler because the are vey specialized and narrow programming constructs that take great pains to circumvent many compiler areas and certainly dynamic libraries. I was very surprised that I turned up 3 cases that got real attention from the linux folks. (One had nothing to do with the compiler; just SCSI controller stuff) -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32387
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #12 from malitzke at metronets dot com 2007-06-19 23:57 --- Why is this still unconfirmed after the corrobation by Mrs Johnson? Personally I could not care less if it is swept under the rug, like so many other PR's. Without-altivec would suit me fine as altivec is, to me, just a competive and unnecessary competitive response, by then Motorola, to Intel's SSE, which to me is just gumming up the X86 part of the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #14 from malitzke at metronets dot com 2007-06-21 00:53 --- This whole series of postings from myself had one aim: to _shame_ Messrs David Edelsohn an Geoff Keating to step up to their resposibilities. You, Pinski, are not listed as a maintainer for RS600; they are. Mr Keating, form the ChangeLog is connected in some way with Apple (ex Computer). Apple dumped RS6000 quite some time ago in favor of i386 and his more recent patches reflect that. Maybe he should vacate that gcc slot for somebody else. I am sorry that have to be that explicit in this forum, but my patience just gave out. If somebody take offense so be it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug c/32447] New: without-decimal-float needed
include -I../../gcc-4.3.0/gcc/../libcpp/include
-I../../gcc-4.3.0/gcc/../libdecnumber -I../../gcc-4.3.0/gcc/../libdecnumber/dpd
-I../libdecnumber-o build/genrecog.o ../../gcc-4.3.0/gcc/genrecog.c
I asked for a quote of that new IBM P 570 computer to put this matter into
perspective.
In my opinion decimal float should have been handled like libiconv (GNU charset
conversion library for libc which doesn't implement it).
Further info in PR32314.
bugzilla will not accept [EMAIL PROTECTED]
--
Summary: without-decimal-float needed
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
GCC target triplet: any architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32447
[Bug c/32447] without-decimal-float needed
--- Comment #1 from malitzke at metronets dot com 2007-06-21 08:08 --- Disclosure: I am not an IBM hater and never was. My first significant program ran on an IBM 1410 with a Tape Operating System (TOS) on the day President Kennedy was assassinated. I then used an IBM 1620 II extensively.; migrated to an IBM 1800 and to an IBM 1130. All worked well for these early systems, but, I had to open the door fairly often late at night for an IBM customer service man. At another firm I worked with the then largest and newest IBM 360's. Overall, I had twice teams come from the Almaden Labs to resolve issues with DASD's and the FORTRAN H compiler (early seventies). On the other hand I really got to hate PL/I, as I could interpret ABEND dumps and colleagues came to my office with 1-2 feet high dumps that mostly by the PL/I compiler going off on a tangent. This interfered with my work and I turned to satellite telecommunications. I only returned to programming as a hobby and as a retirement activity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32447
[Bug middle-end/32447] without-decimal-float needed
--- Comment #3 from malitzke at metronets dot com 2007-06-21 14:33 --- Thanks for helping out again. Enjoy Japan. I was there quite often, dealing with NEC and Mitsubishi, but as a buyer representative for for multi-million $ projects. At that level it was pleasure to do business, even enduring sitting cross-legged on the floor; washing down raw fish with japanese whiskey on the rocks. But to matters at hand. What is called a compiler is actually a crime against traditional usage of the term. "compilare to plunder; 1: to collect into a volume 2: to compose out of materials from other documents" this more accurately describes the function of a traditional loader. A, so-called, compiler is really a translator. In the case of GCC the Italian saying "tradutore; traditore" translator; traitor seems appropriate. I know how hard it is to do technical translation, but that was my first well-paid career at about 15 years of age. My third career was being a real-time assembly language programmer. I received a letter of commendation as a super-programmer for committing the following programming crimes 1) jumping into the middle of instructions; 2) writing self-modifying code. You do what you have to do to put food on the table. I actually jeopardized a three month engagement by showing with the help of simple queuing theory that the project (in-spite of the above tricks) was doomed to fail. The COBOL manager assured me that I was doing a marvelous job squeezing code into 128 byte overlays and not to worry about over-all design. They bought back that contract. In my fourth career I was termed by the company president to-be "our secret weapon" for writing specifications, contracts, and inter-national standards that with-stood the test of legality but were blatantly uni-sided in favor of my employer (very good money). Now, being retired and considering the C and FORTRAN compilers as quite important tools in my UNIX tool-chest; I am trying to prevent GCC being destroyed by mis-interpretation and mis-use of standards legal shenanigans, etc. My loyalty is to "my" tools and not to the people involved with GCC or even GCC as now interpreted. See PR32347. Incidentally, two quotes from K&R "Again because the language reflects the capabilities of current computers, C programs tend to be efficient enough that there is no compulsion to write assembly language instead" (Intro 1st ed). '(ANSI) established a committee whose goal was to produce "and unambiguous and machine-independent definition of the language C" while still _retaining_ its _spirit_'. Preface 2nd Ed, emphasis added. Ritchie got a "Turing Award" and the current crop of people should respect the creator's wishes. If they want to make changes against that original design and call it something else; just as Ritchie acknowledges BCPL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32447
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #11 from malitzke at metronets dot com 2007-06-21 21:13 --- After you solve that there is that little matter of udivdi3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #15 from malitzke at metronets dot com 2007-06-22 12:51 --- > > After you solve that there is that little matter of udivdi3. > udivdi3? In comment 7 somebody (dcb) remarked about PR31654 (marked duplicate to this bug) was impeding kernel compilation. In comment 10 it was reiterated that the importance of the present bug related to kernel compilation. At least for the x86 kernels I never got to the present bug because with gcc-4.3 there is the ugly fact that a recognized __stupid__ and unwarranted optimization per PR31990 downgraded to less than trivial status as an enhancement in PR32044 is impeding kernel compilation. Great fun (not function). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #19 from malitzke at metronets dot com 2007-06-23 15:39 ---
Thank you Mr Hubicka for solving this. I had earlier used your patch from
comment 16 but i had to apply it by hand as my patch-2.5.9 (Larry Wall) would
take that published patch even after html2text; changing --- gimplify.c to
gimplify.c.old; deleting all text after the second @@. Maybe what is published
on bugzilla is no intended for outsiders like myself and works only with CVS,
subversion. However, doing it by hand enabled me to compile cdrutils
(Schilling) and erase an CD-RW.
Could you or somebody else clarify what patch program to use or state that
original reporters of PR's should refrain from using the posted patches.
Now to comments 7, 10, 11, 13, 15 the vital difference is that _dcb_ and
apparently Mr Guenther used a 64-bit machine while I am using a 32-bit.
Question is it the policy of the gcc community to render all 32-bit machines
obsolete for later versions of gcc-4.{3-9}.x? just like certain C constructs
are first marked as disparaged and subsequently rendered unacceptable.
I believe that the requested clarification should be made available to users at
large. Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug c/32493] New: gcc-20070624 fails linux-kernel due to changed gcc-inlining
gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-nls --disable-multilib --disable-werror --disable-libunwind-exceptions --disable-checking --disable-decimal-float --enable-shared --enable-tls --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,fortran --with-cpu=pentium3 --with-system-zlib Thread model: posix gcc version 4.3.0 20070624 (experimental) /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -E -quiet -nostdinc -v -Iinclude -Iinclude/asm-i386/mach-default -D__KERNEL__ -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(main) -DKBUILD_MODNAME=KBUILD_STR(main) -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include -include include/linux/autoconf.h -MD init/.main.o.d init/main.c -m32 -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium3 -maccumulate-outgoing-args -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-aliasing -fno-common -freg-struct-return -ffreestanding -fomit-frame-pointer -fno-stack-protector -O2 -fpch-preprocess -o main.i #include "..." search starts here: #include <...> search starts here: include include/asm-i386/mach-default /usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include End of search list. /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -fpreprocessed main.i -quiet -dumpbase main.c -m32 -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium3 -maccumulate-outgoing-args -auxbase-strip init/main.o -O2 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Wdeclaration-after-statement -Wno-pointer-sign -version -fno-strict-aliasing -fno-common -freg-struct-return -ffreestanding -fomit-frame-pointer -fno-stack-protector -o main.s GNU C version 4.3.0 20070624 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070624 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 081e2e4443ad5c116718923aa10a21d4 include/linux/kallsyms.h: In function 'kernel_init': include/linux/kallsyms.h:82: sorry, unimplemented: inlining failed in call to '__check_printsym_format': recursive inlining include/linux/kallsyms.h:97: sorry, unimplemented: called from here include/linux/kallsyms.h:82: sorry, unimplemented: inlining failed in call to '__check_printsym_format': recursive inlining include/linux/kallsyms.h:97: sorry, unimplemented: called from here include/linux/kallsyms.h:82: sorry, unimplemented: inlining failed in call to '__check_printsym_format': recursive inlining include/linux/kallsyms.h:97: sorry, unimplemented: called from here include/linux/kallsyms.h:82: sorry, unimplemented: inlining failed in call to '__check_printsym_format': recursive inlining include/linux/kallsyms.h:97: sorry, unimplemented: called from here -- Summary: gcc-20070624 fails linux-kernel due to changed gcc- inlining Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets 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=32493
[Bug c/32493] gcc-20070624 fails linux-kernel due to changed gcc-inlining
--- Comment #1 from malitzke at metronets dot com 2007-06-25 10:15 --- Created an attachment (id=13782) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13782&action=view) standrd *.i file drivers/acpi/ec.c:124: sorry, unimplemented: inlining failed in call to 'acpi_ec_write_cmd': recursive inlining drivers/acpi/ec.c:129: sorry, unimplemented: inlining failed in call to 'acpi_ec_write_data': recursive inlining drivers/acpi/tables/tbfadt.c:128: sorry, unimplemented: inlining failed in call to 'acpi_tb_init_generic_address': recursive inlining drivers/scsi/aic7xxx/aic7xxx_osm.h:418: sorry, unimplemented: inlining failed in call to 'ahc_outb': recursive inlining include/asm/desc.h:147: sorry, unimplemented: inlining failed in call to '_set_gate': recursive inlining include/asm/desc.h:38: sorry, unimplemented: inlining failed in call to 'pack_descriptor': recursive inlining include/asm/io.h:181: sorry, unimplemented: inlining failed in call to 'writeb': recursive inlining include/asm/io.h:185: sorry, unimplemented: inlining failed in call to 'writew': recursive inlining include/asm/io.h:341: sorry, unimplemented: inlining failed in call to 'outb': recursive inlining include/asm/io.h:341: sorry, unimplemented: inlining failed in call to 'outb_p': recursive inlining include/linux/device.h:575: sorry, unimplemented: inlining failed in call to 'dev_dbg': recursive inlining include/linux/kallsyms.h:82: sorry, unimplemented: inlining failed in call to '__check_printsym_format': recursive inlining include/linux/kernel.h:237: sorry, unimplemented: inlining failed in call to 'pr_debug': recursive inlining include/linux/pci.h:520: sorry, unimplemented: inlining failed in call to 'pci_write_config_byte': recursive inlining include/linux/pci.h:524: sorry, unimplemented: inlining failed in call to 'pci_write_config_word': recursive inlining include/linux/vt_buffer.h:32: sorry, unimplemented: inlining failed in call to 'scr_memsetw': recursive inlining include/net/tcp.h:693: sorry, unimplemented: inlining failed in call to 'tcp_set_ca_state': recursive inlining include/video/vga.h:265: sorry, unimplemented: inlining failed in call to 'vga_w': recursive inlining include/video/vga.h:347: sorry, unimplemented: inlining failed in call to 'vga_wseq': recursive inlining net/core/dev.c:285: sorry, unimplemented: inlining failed in call to 'netdev_set_lockdep_class': recursive inlining -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32493
[Bug c/32494] New: gcc-4.3.x _32-bit_ becoming irrelevant to kernel
On Fri, 18 May 2007, Andrew Morton wrote: > > gcc-4.3 appears to have cunningly converted this: Very cunning indeed. Considerign that gcc converted straightforward and simple code to a total disaster with a 64-bit divide, I'd call it a gcc bug. > into a divide-by-10 operation, so it emits a call to udivdi3 and we > don't link. I think the proper fix is to just tell people that version of gcc is broken. Linus If anybody wonders where this quote came from; just google "udivdi3 gcc". Current gcc-20070623 message: ld -m elf_i386 -m elf_i386 -o .tmp_vmlinux1 -T arch/i386/kernel/vmlinux.lds arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/built-in.o --start-group usr/built-in.o arch/i386/kernel/built-in.o arch/i386/mm/built-in.o arch/i386/mach-default/built-in.o arch/i386/crypto/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/i386/lib/lib.a lib/built-in.o arch/i386/lib/built-in.o drivers/built-in.o sound/built-in.o arch/i386/pci/built-in.o arch/i386/power/built-in.o net/built-in.o --end-group kernel/built-in.o: In function `getnstimeofday': (.text+0x1eba5): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1ecca): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1f0f4): undefined reference to `__udivdi3' make: *** [.tmp_vmlinux1] Error 1 For more details see PR31541 PR32044 PR31990 -- Summary: gcc-4.3.x _32-bit_ becoming irrelevant to kernel Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets 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=32494
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #5 from malitzke at metronets dot com 2007-06-25 12:50 --- Ping? -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #3 from malitzke at metronets dot com 2007-06-25 12:35 --- Ping? -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #8 from malitzke at metronets dot com 2007-06-25 13:03 --- Ping? -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug c/32496] New: fno-builtin-* not working
quot;
# 1 "rmg3.c"
int rmg(void);
int main(void)
{
return rmg();
}
int rmg(void)
{
static unsigned long long nsec = 0;
static int sec = 0;
while (sec < 1 ) {
nsec++;
if (nsec < 10UL, 0) ;
else
while (__builtin_expect( nsec >= 10UL, 0) ) {
nsec -= 10UL;
++sec;
}
}
return sec;
}
--
Summary: fno-builtin-* not working
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets 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=32496
[Bug c/32501] New: freestanding ___32bit___ avoidance of libgcc.a and libgcc.so
00UL
int rmg(void);
int main(void)
{
/* int sec; */
return rmg();
}
int rmg(void)
{
static unsigned long long nsec = 0;
static int sec = 0;
while (sec < 1 ) {
nsec++;
if (nsec < NSEC_PER_SEC, 0) ;
else
while (__builtin_expect( nsec >= NSEC_PER_SEC, 0) ) {
nsec -= NSEC_PER_SEC;
++sec;
}
}
return sec;
}
# 1 "rmg3.c"
# 1 ""
# 1 ""
# 1 "rmg3.c"
int rmg(void);
int main(void)
{
return rmg();
}
int rmg(void)
{
static unsigned long long nsec = 0;
static int sec = 0;
while (sec < 1 ) {
nsec++;
if (nsec < 10UL, 0) ;
else
while (__builtin_expect( nsec >= 10UL, 0) ) {
nsec -= 10UL;
++sec;
}
}
return sec;
}
--
Summary: freestanding ___32bit___ avoidance of libgcc.a and
libgcc.so
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32501
[Bug c/32501] freestanding ___32bit___ avoidance of libgcc.a and libgcc.so
--- Comment #2 from malitzke at metronets dot com 2007-06-25 16:38 --- I want to reiterate that I am as little a linux-kernel maintainer as I am a GCC maintainer. The linux-kernel is in excellent hands and does not need me. Out of sheer laziness and/or intellectual poverty the example given was cribbed from the kernel and extensively modified by myself. I am doing this as retiree (not needing a job) in regards as a former (30 years ago) real-time assembly programmer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32501
[Bug c/32501] freestanding ___32bit___ avoidance of libgcc.a and libgcc.so
--- Comment #3 from malitzke at metronets dot com 2007-06-25 16:39 --- ping -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32501
[Bug c/32501] freestanding ___32bit___ avoidance of libgcc.a and libgcc.so
--- Comment #4 from malitzke at metronets dot com 2007-06-25 16:39 --- ping -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32501
[Bug c/32501] freestanding ___32bit___ avoidance of libgcc.a and libgcc.so
--- Comment #7 from malitzke at metronets dot com 2007-06-25 16:52 --- ping -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32501
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #10 from malitzke at metronets dot com 2007-06-25 17:01 --- ping -- malitzke at metronets dot com changed: What|Removed |Added CC|rguenth at gcc dot gnu dot |mark at codesourcery dot com |org | Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug c/32501] freestanding ___32bit___ avoidance of libgcc.a and libgcc.so
--- Comment #9 from malitzke at metronets dot com 2007-06-25 17:02 --- Read the standard -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32501
[Bug c/32493] gcc-20070624 fails linux-kernel due to changed gcc-inlining
--- Comment #3 from malitzke at metronets dot com 2007-06-27 16:44 --- I read that the last word ___unfortunate___ means that "to hell with the users; We hold fast to our principles" So now we have two cases that gcc-4.3.x pretty irrelevant. The is that inane transformation of subtraction in a division (the udivdi3 case) and now this one. Well, there exist three paths open to the user community: 1) The blas-atlas that just termed the whole gcc-3.x.y unusable for their purposes. 2) The xfree86-xorg fork. It might be instructive to check the top 25 distribution as ranked by Distrowatch as to who still uses xfree86 in the table of packages used by each distribution (just click on the name of the distribution in the right hand collunm). They all use xorg; but check for yourself. Personally I might be persuaded to in forming such a group. 3) Somebody with greater perspective might read the introduction to "rationale for International Standard Programming Languages C" revison 5.10, April-2003 (google C99 std rationale) and draw appropriate conclusion. BTW doesn't the the reduced case make into "confirmed" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32493
[Bug middle-end/32493] [4.3 Regression] Fails to inline varargs function with unused arguments
--- Comment #6 from malitzke at metronets dot com 2007-06-27 20:43 --- This appears to be the essence of what I wanted note per 3) in comment 3 In going from pdf to html via pdftohtml I was forced to do some realigning and erase special symbols by hand. If you do not trust go to the actual document. If this is what bound the standardization committee it is certainly binding on myself the GCC apparently feels differently. The Xfree86-xorg inspires me to believe that reason will prevail one way or another. The original X3J11 charter clearly mandated codifying common existing practice, and the C89 Committee held fast to precedent wherever that was clear and unambiguous. The vast majority of the language defined by C89 was precisely the same as defined in Appendix A of the first edition of The C Programming Language by Brian Kernighan and Dennis Ritchie, and as was implemented in almost all C translators of the time. (That document is hereinafter referred to asK&R.) K&R was not the only source of existing practice. Much work had been done over the years to improve the C language by addressing its weaknesses, and the C89 Committee formalized enhancements of proven value which had become part of the various dialects of C. This practice has continued in the present Committee. Existing practice, however, has not always been consistent. Various dialects of C have approached problems in different and sometimes diametrically opposed ways. This divergence has happened for several reasons. First, K&R, which once served as the language specification for almost all C translators, is imprecise in some areas (thereby allowing divergent interpretations), and it does not address some issues (such as a complete specification of a library) important for code portability. Second, as the language has matured over the years, various extensions have been added in different dialects to address limitations and weaknesses of the language; but these extensions have not been consistent across dialects. One of the C89 Committee's goals was to consider such areas of divergence and to establish a set of clear, unambiguous rules consistent with the rest of the language. This effort included the consideration of extensions made in various C dialects, the specification of a complete set of required library functions, and the development of a complete, correct syntax for C. Much of the Committee's work has always been in large part a balancing act. The C89 Committee tried to improve portability while retaining the definition of certain features of C as machine-dependent, it attempted to incorporate valuable new ideas without disrupting the basic structure and fabric of the language, and it tried to develop a clear and consistent language without invalidating existing programs. All of the goals were important and each decision was weighed in the light of sometimes contradictory requirements in an attempt to reach a workable compromise. In specifying a standard language, the C89 Committee used several principles which continue to guide our deliberations today. The most important of these are: Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The C89 Committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. On the other hand, no one implementation was held up as the exemplar by which to define C. It was assumed that all existing implementations must change somewhat to conform to the Standard. C code can be portable. Although the C language was originally born with the UNIX operating system on the PDP-11, it has since been implemented on a wide variety of computers and operating systems. It has also seen considerable use in cross-compilation of code for embedded systems to be executed in a free-standing environment. The C89 Committee attempted to specify the language and the library to be as widely implementable as possible, while recognizing that a system must meet certain minimum criteria to be considered a viable host or target for the language. C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the C89 Committee did not want to force programmers into writing portably, to preclude the use of C as a high-level assembler: the ability to write machine-specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program . Avoid quiet changes. Any change to widespread practice altering the meaning of existing code causes problems. Changes that cause code to be so ill-formed as to require diagnostic messages are at least easy to detect. As much as seem
[Bug middle-end/32493] [4.3 Regression] Fails to inline varargs function with unused arguments
--- Comment #8 from malitzke at metronets dot com 2007-06-27 21:34 --- Glad it hit the spot and hopefully alerted the user community as to what is going on. Now, how about doing something about transforming a clearly expressed subtraction into a udivdi3. To the best of my knowledge and research the kernel does not even make the minuend or the subtrahend into a long-long and still the udivdi3 is rammed down the user community's throat. In my toy program (because of the GCC maintainers insistence that everything be reduced I resorted to long-long). This udivdi3 issue was swept by you, Mr. Guenther under the rug by making it an enhancement of severity less than trivial. As I was clearly rejected by the GCC insiders in my attempts to help make the C compiler more attuned to the spirit of the C99 committee; I am now forced to alert the user community of what is happening with near monopoly. And why is a GCC maintainer, with priveledged access to GCC's bugzilla, and hence a spokesperson for the GCC community claiming again and again on GCC's bugzilla that Mr Linus Torvalds is wrong, instead of having the guts to confront Mr torvalds directly. I do not work for Mr Torvalds nor am I part of the the kernel community to deliver an inane message to somebody of the stature of Mr Torvalds. Actually it is evidently clear that Mr Linus Torvalds and Mr Andrew Morton do not need my help. I am actually pursuing this on my own as part of a larger picture. As an outsider GCC's bugzilla is the equivalent to the leads of the good old EE black box. You use use the tools available. Signed Ray Malitzke. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32493
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #12 from malitzke at metronets dot com 2007-06-28 03:53 ---
Mr Pinski! Thanks for again doing the work for me.
I just had to take some time out for my annual checkup and to rebuild my big
machine's software after Gentoo on shutdown -h now deleted my /bin, /etc, and
/sbin directories. Luckkily Volkering is back in good health and completely
revamped slackware. I do not use redhat because they try to force down my
throat
Gnome and I do not use SUSe because they try to do the same thing with KDE.
I hope the somewhat out of context quotes you provide come from the the real
spec and not the preliminary copy available on the net. GCC should have the
real spec, while I can find better use for my money.
Now to your first sentence in comment 11:
The support obligation (contrary to that sentence is levied on the conforming
implementation and not on the conforming program. Now let us go the the real
issue namely the transformation of unsigned long (not unsigned long long as in
my toy program) minuend and subtrahend subtraction into a 64 bit udivdi3. The
proof of my assertion lies in the fact that for a 64 bit machine the issue
never arises. I, certainly can not speak for Mr. Torvalds, he certainly doe not
need my help, but speaking for myself if find it preposterous a clearly faulty
interpretation of the standard used to ram down __my__ throat a transformation
from a clearly specified subtraction into a udivdi3 division.
The erroneous interpretation stems from a complete ignorance (feigned or
actual)
of a non reflexive relation between program (this is the part missing from your
quote) and implementation into a reflexive. or, worse, equivalence relation.
I never disputed the fact that under the standard even the free-standing
implementation has an obligation to to provide udivdi3 for 32 bit machines. You
disclosed your ignorance or, worse, morally questionable (your choice)
disregard for the real issue, namely trying to cover up a grave deficiency
(bug) in the GNU C compiler by specious arguments in using a division, instead
of the subtraction in your comment 1. If I or the kernel people had specified
an actual division, instead of a carefully circumscribed subtraction we would
have gotten what we deserved.
Yes, Mr Morton, looked for alternatives in order to avoid a confrontation, I am
not as conciliatory. In my opinion Mr. Torvalds hit the nail right on the head.
As an aside, I am not your messenger boy to propagate your ignorance or
maliciousness to third parties.
If this goes unchallenged the next possible result could be as follows:
Some GCC maintainer, claiming register pressure would resort to the following:
All Pentium CPU's have a floating point unit and there exists an integer load
and store operation for that floating point unit. Last time I looked floating
register, plus flags, save and restore are not atomic hence reentrancy goes
down the drain which potentially fatal results.
The remainder clearly shows that some members of the GCC community agree that I
as a user have right to avoid having this inane substitution rammed down my
throat. Unfortunately thei proposed remedies either do not work or do not avoid
the real issue:
It would of course be easy to prevent the optimization by declaring nsec to be
volatile. The question is whether the compiler can reasonably determine that
the optimization is inappropriate in this particular case.
Richard Guenther
an optimization issue and __udivdi3 can be
avoided
by using volatile as stated and verified.
Manuel López-Ibáñez
Isn't there a way for __builtin_expect to modify this behaviour? After all, it
is telling us that the loop is cheap. And the difference in computation time is
not trivial at all.
The volatile fix would be fine, but (at least for me) does not work with the
kernel. There is that little message:
kernel/time.c:479: warning: passing argument 3 of 'div_long_rem_signed'
discards qualifiers from pointer target type.
and others like it, and, udivdi3 reappears.
Thank you (muchas gracias) for looking at the matter from a user's point of
view and considering my arguments concerning __builtin_expect. You seem to be
the first to look at the timings and amount of code generated. If you are
interested I have equivalent data taken on a MAC with dual G4's. I did not send
it so far because until you intervened I got mostly legalistic arguments and
proposed fixes that do no solve the real problem of avoiding both udivdi3 and
more importantly libgcc.
Richard Guenther
So this is now an enhancement request for sccp to honor loop roll count or
basic-block frequency and cost of the replacement. Note the loop appears to be
peeled twice before sccp already, but peeling doesn't decay probabilities
further.
Testcase:
int rmg(unsigned long long nsec)
{
int sec = 0;
nsec++;
while (__builtin_expect(nsec >= 10UL, 0)) {
nsec -= 10UL;
[Bug c/32496] fno-builtin-* not working
--- Comment #2 from malitzke at metronets dot com 2007-06-28 04:45 --- Iam soory Mr. Schwab but the fno-builtin was provide to me by a fellow maintainer I am just exhausting all offered approaches to avoid having a subtraction changed to a libgcc-function/builtin The flag just disables an optimisation. If you want to disable optimisations just use -O0. On the other hand, shouldn't -ffreestanding prevent udivdi3 ? What about -fno-builtin-udivdi3 ? Any constructive suggestions? -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32496
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #14 from malitzke at metronets dot com 2007-06-29 21:14 --- The first two sentences of your comment was never disputed by either myself nor from how I read Mr Torvald's comment. The only thing under dispute is the completely unwarrented trnasformation of a subtraction into a division. I am not speaking for the kernel people here but for myself; their subtraction just started me off. There are vey good reasons to avoid ligcc, like atomicity, reentrancy or plain orneryness. If I clearly specify a subtraction any C compiler worthy of its name has no right transform that subtraction into a division and then claim that substitution of entitles GCC to ram libgcc down my throat. In freestanding program I do not want, and apparently the linux kernel, does not want libgcc painted any color. It is our prerogative to specify the operations we want. In hosted programs it might not be worthwhile fighting aganst the under-handed way libgcc is dragged (remember ldd does not show its use). Even the US Supreme Court looks at the drafting process preceeding the Constitution and any laws passed by Congress. Now the below Is what boud the C99 committee in drafting the standard. If this is what bound the standardization committee it is certainly binding on myself the GCC apparently feels differently. The Xfree86-xorg inspires me to believe that reason will prevail one way or another. The original X3J11 charter clearly mandated codifying common existing practice, and the C89 Committee held fast to precedent wherever that was clear and unambiguous. The vast majority of the language defined by C89 was precisely the same as defined in Appendix A of the first edition of The C Programming Language by Brian Kernighan and Dennis Ritchie, and as was implemented in almost all C translators of the time. (That document is hereinafter referred to asK&R.) K&R was not the only source of existing practice. Much work had been done over the years to improve the C language by addressing its weaknesses, and the C89 Committee formalized enhancements of proven value which had become part of the various dialects of C. This practice has continued in the present Committee. Existing practice, however, has not always been consistent. Various dialects of C have approached problems in different and sometimes diametrically opposed ways. This divergence has happened for several reasons. First, K&R, which once served as the language specification for almost all C translators, is imprecise in some areas (thereby allowing divergent interpretations), and it does not address some issues (such as a complete specification of a library) important for code portability. Second, as the language has matured over the years, various extensions have been added in different dialects to address limitations and weaknesses of the language; but these extensions have not been consistent across dialects. One of the C89 Committee's goals was to consider such areas of divergence and to establish a set of clear, unambiguous rules consistent with the rest of the language. This effort included the consideration of extensions made in various C dialects, the specification of a complete set of required library functions, and the development of a complete, correct syntax for C. Much of the Committee's work has always been in large part a balancing act. The C89 Committee tried to improve portability while retaining the definition of certain features of C as machine-dependent, it attempted to incorporate valuable new ideas without disrupting the basic structure and fabric of the language, and it tried to develop a clear and consistent language without invalidating existing programs. All of the goals were important and each decision was weighed in the light of sometimes contradictory requirements in an attempt to reach a workable compromise. In specifying a standard language, the C89 Committee used several principles which continue to guide our deliberations today. The most important of these are: Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The C89 Committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. On the other hand, no one implementation was held up as the exemplar by which to define C. It was assumed that all existing implementations must change somewhat to conform to the Standard. C code can be portable. Although the C language was originally born with the UNIX operating system on the PDP-11, it has since been implemented on a wide variety of computers and operating systems. It has also seen considerable use in cross-compilation of code for embedded systems to be executed in a free-standing environment. The C89 Committ
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #16 from malitzke at metronets dot com 2007-06-29 21:42 --- A treaty is a bilateral agreement. No something shoved down one Side throat. The worse I look the more I accomplish for others than GCC fanatics -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
