From: SourceForge.net <no...@so...> - 2009-09-01 12:28:17
|
Bugs item #2834786, was opened at 2009-08-10 05:12 Message generated for change (Settings changed) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2834786&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: Waiting User Response >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: gcc 4.4.0 Error code generation with -O3 Initial Comment: I tried to compile Qt 4.5.2 on mingw gcc 4.4.0. Options optimization release: QMAKE_CFLAGS_RELEASE = -O3 -march=pentium3 -mtune=pentium3 To build without errors, but when you start assistant.exe get an error in QtCode4.dll. The same error I get when running assistant_adp.exe when you try to click on a link. Running under gdb assistant.exe of shows at the function inflate (inflate.c) and inflate_table (inftrees.c) from the directory qt4/src/3rdparty/zlib (copy of zlib 1.2.3) Disasembler line in gdb: movaps %xmm0,-0x28(%ebp) After the change -O3 to -O2 and rebuilding QtCode4.dll error disappeared. However, there are similar errors in other modules. For example in QtGui4.dll (gdb log tail): [code] ... (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. 0x679f3c68 in ZNK12QCommonStyle18drawComplexControlEN6QStyle14ComplexControlEPK19QStyleOptionComplexP8QPainterPK7QWidget () from C:\Lang\qt\qt4\bin\QtGui4.dll (gdb) display/i $pc 1: x/i $pc 0x679f3c68 <ZNK12QCommonStyle18drawComplexControlEN6QStyle14ComplexControlEPK19QStyleOptionComplexP8QPainterPK7QWidget+73448>: movaps %xmm0,-0x278(%ebp) (gdb) p $ebp $1 = (void *) 0x21ca94 (gdb) [/code] ---------------------------------------------------------------------- >Comment By: Earnie Boyd (earnie) Date: 2009-09-01 08:28 Message: This all sounds like a programming bug with memory pointers. The problem just hides with -O2 versus is presented with -O3 because the memory references are different. Provide a small test case of the problem to help prove your point. ---------------------------------------------------------------------- Comment By: Alexandr Zamaraev (shura_zam) Date: 2009-09-01 06:10 Message: Also sampe - dybase-020 for Python from http://www.garret.ru/dybase.html I change python distutils compile option to: -O3 -mtune=pentium3 -march=pentium3 After biuld and install test script testmap.py chash: [code] (gdb) r testmap.py Starting program: c:/Lang/python/26/python.exe testmap.py [New thread 3980.0x7c0] (no debugging symbols found) (no debugging symbols found) ... (no debugging symbols found) warning: while parsing target library list: not well-formed (invalid token) warning: Temporarily disabling breakpoints for unloaded shared library "C:\Windo ws\system32\msvcrt.dll" warning: while parsing target library list: not well-formed (invalid token) warning: while parsing target library list: not well-formed (invalid token) Database initialized Program received signal SIGSEGV, Segmentation fault. 0x66b11c88 in ?? () (gdb) display/i $pc 1: x/i $pc 0x66b11c88: movaps %xmm1,-0x78(%ebp) (gdb) p $ebp $1 = (void *) 0x21fb60 (gdb) [/code] All entry instructions (movaps %xmm1,-120(%ebp)) are within the functions dbDatabase:: commitTransaction ---------------------------------------------------------------------- Comment By: Alexandr Zamaraev (shura_zam) Date: 2009-08-13 02:07 Message: I think this is some other problem. After all, crach occurs on the instructions of the stack rather than the global data: movaps %xmm0,-0x28(%ebp) or movaps %xmm0,-0x278(%ebp) More akin to the situation described here: http://sourceforge.net/tracker/?func=detail&atid=102435&aid=2834267&group_id=2435 ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2009-08-13 01:35 Message: This looks like a problem with (un)aligned common. Try adding -fno-common to compile options. See also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216 and try ---------------------------------------------------------------------- Comment By: Alexandr Zamaraev (shura_zam) Date: 2009-08-13 00:13 Message: As far as I can judge, in the code where the fault is with the floating-point computations are not used (zlib 1.2.3). The compiler inserts instructions sse to optimize the initialization of local variables. Can you suggest a search for the minimum reproducible test? ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2009-08-10 08:44 Message: And what makes this a GCC bug instead of a bug in the code that doesn't know how to handle the additional optimizations? Find a smaller test case that proves the bug and attach it to this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2834786&group_id=2435 |