We built qt-3.3.2 and kde-3.3.2 using gcc-3.4.3. We did the same on HP-UX 11.x, Redhat Linux, and Redhat Enterprise Linux. http://lists.kde.org/?l=kde-devel&m=110384477320197&w=2 On Solaris/SPARC, we're seeing a problem. None of the other platforms have a problem. I was able to work around the bug in the above message with the diff below to one of the KDE source files. Unfortunately, I cannot isolate this to a small test case. I'm building on gax as follows: g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../dcop -I../../kio/kssl -I../.. -I./.. -I./../kssl -I../kssl -I./../../interfaces -I../../dcop -I../../libltdl -I../../kdefx -I../../kdecore -I../../kdeui -I../../kio -I../../kio/kio -I../../kio/kfile -I../.. -I/opt/TWWfsw/libqt33/include/gcc34 -I/opt/TWWfsw/kde33/include -I/opt/TWWfsw/bzip2/include -I/opt/TWWfsw/jpeg/include -I/opt/TWWfsw/libpcre44/include -I/opt/TWWfsw/libpng12/include -I/opt/TWWfsw/libxslt11/include -I/opt/TWWfsw/libxml26/include -I/opt/TWWfsw/libtiff35/include -I/opt/TWWfsw/zlib11/include -I/opt/TWWfsw/libart23/include -I/opt/TWWfsw/fcpackage22/include -I/opt/TWWfsw/libaudiofile02/include -I/opt/TWWfsw/cups1120r/include -I/opt/TWWfsw/libopenssl097/include -D_LARGEFILE64_SOURCE -DQT_THREAD_SUPPORT -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DUSE_SOLARIS -DSVR4 -DNDEBUG -DNO_DEBUG -isystem /usr/openwin/include -g -finline-functions -mcpu=v8 -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -c kurlcompletion.cpp --- kdelibs-3.3.2/kio/kio/kurlcompletion.cpp.orig Thu Dec 23 17:56:26 2004 +++ kdelibs-3.3.2/kio/kio/kurlcompletion.cpp Thu Dec 23 19:11:59 2004 @@ -225,6 +225,7 @@ // Loop through all directory entries +int i; struct dirent dirPosition; struct dirent *dirEntry = 0; while ( !terminationRequested() &&
The patch below, somewhat similar to the patch in the original message with the workaround, does *not* work. The only difference between the two is where "int i;" is placed. --- kio/kio/kurlcompletion.cpp.orig Thu Dec 23 17:56:26 2004 +++ kio/kio/kurlcompletion.cpp Thu Dec 23 19:24:10 2004 @@ -226,6 +226,7 @@ // Loop through all directory entries struct dirent dirPosition; +int i; struct dirent *dirEntry = 0; while ( !terminationRequested() && ::readdir_r( dir, &dirPosition, &dirEntry ) == 0 && dirEntry )
Created attachment 7815 [details] .ii file using the original workaround patch
Created attachment 7816 [details] .s file using the original workaround patch
This might not be a sparc back-end bug but a bug in the KDE, they might be overflowing the stack or something else.
Created attachment 7817 [details] .ii file using patch in comment #1
Created attachment 7818 [details] .s file using patch in comment #1
Ok, I ran diff on both .s files (id #7816 v id #7818) and found the following: @@ -199,8 +199,8 @@ cmp %g1, 0 bne .LL9 nop - add %fp, -80, %g1 - add %fp, -84, %o5 * + add %fp, -72, %g1 + add %fp, -80, %o5 ld [%fp-20], %o0 mov %g1, %o1 mov %o5, %o2 If you review the diff of the .s files between #7816 and #7818, the numeric differences are the same except for the line with the '*' above. I modified the .s file and changed -72 to -76 (diff of four from -80 on the next line) and it worked (patch below)! --- id7816/kurlcompletion.s Thu Dec 23 19:20:59 2004 +++ kurlcompletion.s Thu Dec 23 19:40:52 2004 @@ -199,7 +199,7 @@ cmp %g1, 0 bne .LL9 nop - add %fp, -72, %g1 + add %fp, -76, %g1 ld [%fp-20], %o0 mov %g1, %o1
Comment #7 should confirm this is a GCC bug.
(In reply to comment #8) > Comment #7 should confirm this is a GCC bug. Not really, it just showed where the problem is. Can you try the mainline as there has been a couple of sparc bugs which have been fixed there.
I looked at the .s files more closely and comment #7 might be off. Offsets seem to differ by either 4 or 8 not only 8 like I originally thought. I generated the .s files on HP-UX and it had the same 4 or 8 offset difference. I'll test mainline.
This PR is a bit confusing. Please attach the original preprocessed file and post the modification to the original *.s file that appears to fix the bug.
Created attachment 7820 [details] Original pre-processed source
Created attachment 7821 [details] Original pre-processed .s file
Created attachment 7822 [details] Pre-processed source with fix (add "int i;") Note: If the 'int i;' is placed after the 'struct dirent dirPosition;', this solution fails.
Created attachment 7823 [details] Pre-processed .s of kurlcompletion.ii with fix ("int i;" added)
gcc-3.3.2 exhibits the same problem. Maybe I'm wrong?
Cannot test mailing because of an ICE while building qt-3.3.2 with -g.
Oops, "mailing" in comment #17 should be "mainline".
Ok, found the real problem. I was wrong. This is not a GCC bug. It is a KDE bug. On Solaris and IRIX, struct dirent does not contain space for the name of the file. Tru64 UNIX, HP-UX, and GNU/Linux do. So, KDE was simply overwriting memory not belonging to it. Hence, SIGBUS. Sorry!
So closing as invalid. thanks for looking into the bug.