Problems with bootstrapping 4.0.1
I have been having comparison errors while building a native 4.0.1 compiler for my Fedora Core 4 system. I checked the flags for a file I randomly chose, c-pragma.c, and the flags don't differ from initial build of xgcc to stage2. I have included a tarball of the object files for c-pragma.c and a c-pragma-make.err file containing the make outputs when c-pragma.c was compiled. Has any one else experienced this problem on Fedora Core 3 and/or have a solution to the problem? Surprisingly, I have been able to bootstrap the latest gcc on the cvs without any comparison problems, though (since 4.0.2 is prerelease) make check reported a whole bunch of problems. I had to rebuild my system due to an "init" malfunction, so I will have to look on my backups to see if I can find the testcases for submission. c-pragma-4.0.1.tar.bz2 Description: application/bzip-compressed-tar --- WITHOUT OPTIMIZATION --- pre-stage build: gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition-DHAVE_CONFIG_H-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include ../../gcc/c-pragma.c -o c-pragma.o stage1/xgcc -Bstage1/ -B/usr/i686-pc-linux-gnu/bin/ -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wno-error -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include ../../gcc/c-parse.c -o c-parse.o stage2/xgcc -Bstage2/ -B/usr/i686-pc-linux-gnu/bin/ -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wno-error -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include ../../gcc/c-parse.c -o c-parse.o
Re: Problems with bootstrapping 4.0.1
It appears that the gcc included with Fedora Core 4 (or some other program that may be used during gcc bootstrap) does not produce identical output on stages 2 and 3. I ran "make bootstrap4", and the comparison check passed after building stage 4. Any one with Fedora Core 4 will have to run "make bootstrap4" to successfully bootstrap gcc-4.0.x - that's what I noticed. - KJM On Sat, 2005-08-13 at 17:11 -0700, James E Wilson wrote: > Kevin McBride wrote: > > I have been having comparison errors while building a native 4.0.1 > > compiler for my Fedora Core 4 system. > > Running >cmp c-pragma.o stage2/c-pragma.o > on your provided files says that they identical. If you are getting > comparison failures on these files, then perhaps your "cmp" program is > broken. Or perhaps you included the wrong files to look at. > > Your makefile output is a little odd, as you give the compile line for > c-pragma.o first, and then the compile lines for c-parse.o. Probably a > simple cut and paste error. This is probably not relevant anyways. It > is highly unlikely that there is a problem with the gcc command line > args during stage2 or stage3.
memset() Optimization on x86-32 bit
I have a bit of a disagreement with the optimization toward memset() calls. In one of my libraries, libteklti, I have a function named ucharempty(), which frees a uchar_t (unique character structure) from memory. If the user elects to have the memory erased prior to calling free(), memset() is supposed to reset the memory about to be freed. Source code for the libteklti project is on SourceForge at: http://cvs.sourceforge.net/viewcvs.py/libteklti/ Anyway, in gcc 4.0.1, I have noticed that the optimization for memset() calls has a few extra instructions in the generated assembly that do not need to be inserted. If you look closely, you can see that %edi can be automatically loaded directly without problems, and that (%eax) can be directly loaded into (%esp). Is this behavior intentional (for bugs I don't know about in earlier processors) or could this optimization be fixed to use less instructions? The following disassembly output is an example for the line: 0x08049172 : mov0x8(%ebp),%eax 0x08049175 : mov0x4(%eax),%edx 0x08049178 : mov0x8(%ebp),%eax 0x0804917b : mov(%eax),%ebx 0x0804917d : mov%ebx,%edi 0x0804917f : cld 0x08049180 : mov%edx,%ecx 0x08049182 : mov$0x0,%al 0x08049184 : repz stos %al,%es:(%edi) 0x08049186 : mov%ebx,%eax 0x08049188 : mov%eax,(%esp) 0x0804918b : call 0x8048c08 associated C code: #ifdef TEKLTI_ENFORCE_PRIVACY free( memset( uchrtofree->uchar_t_ascii, '\0', sizeof(char) * uchrtofree->uchar_t_asciilen ) ); #else /* not USE_386_ASM_ENFORCE_PRIVACY */ For reference: Dump of assembler code for function ucharempty, for comparison: From uchar.c: 0x0804913d : push %ebp 0x0804913e : mov%esp,%ebp 0x08049140 : push %edi 0x08049141 : push %ebx 0x08049142 : sub$0x10,%esp 0x08049145 : cmpl $0x0,0x8(%ebp) 0x08049149 : jne0x8049172 0x0804914b : mov0x804c1cc,%eax 0x08049150 : mov%eax,0xc(%esp) 0x08049154 : movl $0x35,0x8(%esp) 0x0804915c : movl $0x1,0x4(%esp) 0x08049164 : movl $0x804b120,(%esp) 0x0804916b : call 0x8048c58 0x08049170 : jmp0x804919b 0x08049172 : mov0x8(%ebp),%eax 0x08049175 : mov0x4(%eax),%edx 0x08049178 : mov0x8(%ebp),%eax 0x0804917b : mov(%eax),%ebx 0x0804917d : mov%ebx,%edi 0x0804917f : cld 0x08049180 < ucharempty+67>: mov%edx,%ecx 0x08049182 : mov$0x0,%al 0x08049184 : repz stos %al,%es:(%edi) 0x08049186 : mov%ebx,%eax 0x08049188 : mov%eax,(%esp) 0x0804918b : call 0x8048c08 0x08049190 : mov0x8(%ebp),%eax 0x08049193 : mov%eax,(%esp) 0x08049196 : call 0x8048c08 0x0804919b : add$0x10,%esp 0x0804919e : pop%ebx 0x0804919f : pop%edi 0x080491a0 : pop%ebp 0x080491a1 : ret End of assembler dump. From uchar.386.c: Dump of assembler code for function ucharempty: 0x08048fde : push %ebp 0x08048fdf : mov%esp,%ebp 0x08048fe1 : mov0x8(%ebp),%ecx 0x08048fe4 : push %edi 0x08048fe5 : mov(%ecx),%edi 0x08048fe7 : push %edi 0x08048fe8 : mov0x4(%ecx),%ecx 0x08048feb : mov$0x0,%al 0x08048fed : repz stos %al,%es:(%edi) 0x08048fef : call 0x8048be0 0x08048ff4 : pop%edi 0x08048ff5 : pop%edi 0x08048ff6 : mov%ebp,%esp 0x08048ff8 : pop%ebp 0x08048ff9 : jmp0x8048be0 End of assembler dump.
APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit
Everyone, Please take notice that I am appealing my bug (number 23605) to the steering committee of GCC on the basis that it is a legimate bug/enhancement in need of a through research. I believe that Andrew Pinski is trying to keep the research from occuring by means of marking the bug as invalid. I am hoping that the steering committee will order a through research on the bug. There are times when it might be best to have things like memset() inlined by the compiler itself, as outlined in my latest comment to the bug. - KJM Original Message Subject: [Bug target/23605] memset() Optimization on x86-32 bit Date: 28 Aug 2005 22:21:15 - From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28 22:21 --- First it is not our bug your distro installs i686 versions, go bug them instead. Second glibc not using SSE is its bug and not ours, report it to them instead. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
[DEAD] APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit
Joe Buck wrote: I've looked at the bug in bugzilla; it's not marked as invalid, though I tend to agree with Andrew and Ian's comments in the log. I set the bug back to unconfirmed after I noticed that, in my opinion, there can be more optimization done. In any case, the SC doesn't get involved in cases like this. And even if the SC lost its sanity and decided to micromanage Bugzilla as you ask, it would take a 3/4 vote, and you certainly wouldn't get mine. I didn't realize that the SC had no control over Bugzilla. Unless there was something I missed, all what the web site said was: > In April 1999 the steering committee was appointed by the FSF as the > official GNU maintainer for GCC and changed its name to GCC steering > committee. All I can now say is: If no one on the GCC team wants to fully investigate my bug, then there's nothing I can do about the bug except to implement the fix in my own code. This appeal started up over misunderstandings between Andrew Pinski, Ian Lance Taylor, and I. I felt that Ian Lance Taylor agreed with me prior to submitting the bug to the bug tracker, and so, felt humiliated by Andrew Pinski's comments. When Ian Lance Taylor stepped in, he made the misunderstanding obvious to me, and so, I did what I could to see if gcc was performing optimizations as much as possible. This appeal is now dead. Let's get on with our projects, regardless if my bug report will ever be turned into a bug fix. - KJM
