public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "xiaofengguo at google dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/47979] New: Problem in comparing integers Date: Thu, 03 Mar 2011 20:35:00 -0000 [thread overview] Message-ID: <bug-47979-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47979 Summary: Problem in comparing integers Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned@gcc.gnu.org ReportedBy: xiaofengguo@google.com Hi, Here is a short summary of the problem. In the upgrading of gcc from 3.3 to 4.4.3, my hash unit test failed. I did some investigation and wrote a simple program, which is attached, to reproduce this problem. I use command below to compile this program: g++ -g -pipe -O9 -funroll-loops -ffast-math -DNDEBUG -march=pentiumpro -DLINUX -fpic -DGEOTARGETING -D_NG_POSIX_THREAD -D_RWCONFIG_${RWDBGNUM}_$RWLIBVERSION -DRW_MULTI_THREAD -DRW_NO_XMSG -DRW_POSIX_D10_THREADS -D_REENTRANT -Wall -Werror -Wno-sign-compare -Wno-write-strings -Wno-strict-aliasing -Wno-unused-result abs_error.cc and the result shows me "hash<0" is false. If "-O9" is removed from the command line, "hash<0" is true. I disassembly the obj file by objdump (objdump -Sl a.out), and below is digest of the optimized result: ... 80484f1: b8 49 5e 86 da mov $0xda865e49,%eax 80484f6: 89 e5 mov %esp,%ebp 80484f8: 83 e4 f0 and $0xfffffff0,%esp 80484fb: 53 push %ebx 80484fc: e8 4c 00 00 00 call 804854d <__i686.get_pc_thunk.bx> 8048501: 81 c3 f3 1a 00 00 add $0x1af3,%ebx 8048507: 83 ec 1c sub $0x1c,%esp 804850a: 89 44 24 08 mov %eax,0x8(%esp) 804850e: c7 04 24 01 00 00 00 movl $0x1,(%esp) 8048515: 8d 8b ec e6 ff ff lea -0x1914(%ebx),%ecx 804851b: 89 4c 24 04 mov %ecx,0x4(%esp) 804851f: e8 dc fe ff ff call 8048400 <__printf_chk@plt> 8048524: 8d 83 f7 e6 ff ff lea -0x1909(%ebx),%eax 804852a: ba 49 5e 86 da mov $0xda865e49,%edx 804852f: 89 54 24 08 mov %edx,0x8(%esp) 8048533: 89 44 24 04 mov %eax,0x4(%esp) 8048537: c7 04 24 01 00 00 00 movl $0x1,(%esp) 804853e: e8 bd fe ff ff call 8048400 <__printf_chk@plt> ... Seems "hash" and "result" both assigned 0xda865e49 (-628728247 in oct) directly, for the optimizations. I am not sure whether it is a problem in optimizations of the compiler, so I am not sure whether it is correct for me to assign bug on this component. And, because I am not familiar with i86 assembly, just read some tutorial to understand a bit of the asm code, there must be some problems in the investigations. Please let me know what do you think of this issue. Sure, if it is my problem or there is a duplication of this bug, please let me know and close the bug freely. And, because it is almost impossible for our project to move back to gcc 3.3 or try one more upgrade in short period, would you share me some way for us to walk around this problem? (Sure, to make sure other code won't face this problem any more) Many thanks for your help!
next reply other threads:[~2011-03-03 20:35 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-03-03 20:35 xiaofengguo at google dot com [this message] 2011-03-03 20:36 ` [Bug rtl-optimization/47979] " xiaofengguo at google dot com 2011-03-03 20:38 ` pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-47979-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).