Created attachment 23328 [details] The complete kcontrol/kong build directory at time of segfault Guys, This is the first gcc bug I've ever filed so bare with me. The gcc -v information is: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/lto-wrapper Target: i686-pc-linux-gnu Configured with: /build/src/gcc-4.5-20110127/configure --prefix=/usr --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-gnu-unique-object --enable-lto --enable-plugin --enable-gold --with-plugin-ld=ld.gold --disable-multilib --disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog --with-cloog-include=/usr/include/cloog-ppl --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info Thread model: posix gcc version 4.5.2 20110127 (prerelease) (GCC) The segfault was encountered building kdebase/kcontrol/konq from the Trinity svn tree on Arch Linux i686. The exact error was: [18%] Building CXX object kcontrol/konq/CMakeFiles/kcm_konq-module.dir/fontopts.cpp.o cd /home/david/tbld/kdebase/src/kcontrol/konq && /usr/bin/c++ -Dkcm_konq_module_EXPORTS -DHAVE_CONFIG_H -DUSE_QT3 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -march=i686 -mtune=generic -O2 -pipe -include tqt.h -fPIC -I/home/david/tbld/kdebase/src/kcontrol/konq -I/home/david/tbld/kdebase/src -I/home/david/tbld/kdebase/libkonq -I/opt/trinity/include -I/opt/qt/include -I/opt/qt/include/tqt -o CMakeFiles/kcm_konq-module.dir/fontopts.cpp.o -c /home/david/tbld/kdebase/kcontrol/konq/fontopts.cpp In file included from /home/david/tbld/kdebase/kcontrol/konq/fontopts.cpp:387:0: /home/david/tbld/kdebase/src/kcontrol/konq/fontopts.moc: In member function virtual void KonqFontOptions::load(bool): /home/david/tbld/kdebase/src/kcontrol/konq/fontopts.moc:136:93: 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. make[2]: *** [kcontrol/konq/CMakeFiles/kcm_konq-module.dir/fontopts.cpp.o] Error 1 make[2]: Leaving directory `/home/david/tbld/kdebase/src' make[1]: *** [kcontrol/konq/CMakeFiles/kcm_konq-module.dir/all] Error 2 make[1]: Leaving directory `/home/david/tbld/kdebase/src' make: *** [all] Error 2 Aborting... 12:02 trinity:~/tbld/kdebase> I have created a tar.bz2 of the src/kcontrol/konq directory (which I hope is what you need) and I've attached it. The build arguments were: trinity_prefix="/opt/trinity" cd ${srcdir} cmake ../ \ -DCMAKE_INSTALL_PREFIX=${trinity_prefix} \ -DCMAKE_VERBOSE_MAKEFILE=ON \ -DWITH_QT3=ON \ -DQTDIR=/opt/qt \ -DQT_LIBRARY_DIRS=/opt/qt/lib \ -DBUILD_ALL=ON make VERBOSE=1 Let me know what else you need and I'll be happy to send it. I have run the build a second time and it makes it past the point where it segfaulted, but crashes later on with an error that the Trinity developer cannot explain in a similar class inclusion setting. The second crash output is: [ 29%] Building CXX object kcontrol/iccconfig/CMakeFiles/kcm_iccconfig-module.dir/iccconfig.cpp.o cd /home/david/tbld/kdebase/src/kcontrol/iccconfig && /usr/bin/c++ -Dkcm_iccconfig_module_EXPORTS -DHAVE_CONFIG_H -DUSE_QT3 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -march=i686 -mtune=generic -O2 -pipe -Wall -include tqt.h -fPIC -I/home/david/tbld/kdebase/src/kcontrol/iccconfig -I/home/david/tbld/kdebase/src -I/opt/trinity/include -I/opt/qt/include -I/opt/qt/include/tqt -DKDE_CONFDIR=\"/opt/trinity/share/config\" -o CMakeFiles/kcm_iccconfig-module.dir/iccconfig.cpp.o -c /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp In file included from /opt/qt/include/tqt/tqimage.h:32:0, from /opt/trinity/include/kaboutdata.h:24, from /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:29: /opt/qt/include/qimage.h: In member function ‘bool QImageTextKeyLang::operator<(const QImageTextKeyLang&) const’: /opt/qt/include/qimage.h:58:61: warning: suggest parentheses around ‘&&’ within ‘||’ /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp: In member function ‘void KICCConfig::renameProfile()’: /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:148:6: warning: unused variable ‘i’ /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:149:12: warning: unused variable ‘iccFileArrayNew’ /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp: In member function ‘QString KICCConfig::extractFileName(QString, QString)’: /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:255:1: warning: no return statement in function returning non-void /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp: In member function ‘void KICCConfig::load(bool)’: /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:289:38: error: expected type-specifier /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:289:38: error: cannot convert ‘int*’ to ‘KRandrSimpleAPI*’ in initialization /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:289:38: error: expected ‘,’ or ‘;’ /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp: In member function ‘virtual void KICCConfig::save()’: /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:359:37: error: expected type-specifier /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:359:37: error: cannot convert ‘int*’ to ‘KRandrSimpleAPI*’ in initialization /home/david/tbld/kdebase/kcontrol/iccconfig/iccconfig.cpp:359:37: error: expected ‘,’ or ‘;’ make[2]: *** [kcontrol/iccconfig/CMakeFiles/kcm_iccconfig-module.dir/iccconfig.cpp.o] Error 1 make[2]: Leaving directory `/home/david/tbld/kdebase/src' make[1]: *** [kcontrol/iccconfig/CMakeFiles/kcm_iccconfig-module.dir/all] Error 2 make[1]: Leaving directory `/home/david/tbld/kdebase/src' make: *** [all] Error 2 Aborting... Let me know if you want to see any more of the iccconfig.cpp error information (src, etc..). The segfault is the most compelling error, but if you notice, both the segfault and the iccconfig error follow the load:(bool) calls. Thanks for any help you can provide and just let me know what else you want to see.
> I have run the build a second time and it makes it past the point > where it segfaulted, This means your problem is almost certainly *not* a bug in GCC, but rather a hardware fault: most commonly a bad RAM module. Please run a memory tester against your computer (a good one is at http://www.memtest.org/ ) -- you may have to run it for several hours for definitive results.
(In reply to comment #0) > I have created a tar.bz2 of the src/kcontrol/konq directory (which I hope is > what you need) and I've attached it. http://gcc.gnu.org/bugs/ says we want preprocessed source (generated by using -save-temps) and not an archive of sources. It also says we do not want: An error that occurs only some of the times a certain file is compiled, such that retrying a sufficient number of times results in a successful compilation; this is a symptom of a hardware problem, not of a compiler bug (sorry)
GCC is unlikely to randomly crash like that (especially on Linux) so Zack might be on the right track. Please try to reproduce on another machine.
Thanks guys, The iccconfig.cpp build failure is reproducible 100% of the time on gcc-4.5.2 on both i686 and x86_64 (this error does not exist on gcc43). The kcontrol/kong segfault looks like a side effect of the iccconfig problem. As a test, I built and installed gcc43 and kdelibs builds fine -- (no iccconfig.cpp error and no segfault) The build with gcc43 looked like this: cmake ../ \ -DCMAKE_C_COMPILER="/usr/bin/gcc-4.3" \ -DCMAKE_CXX_COMPILER="/usr/bin/g++-4.3" \ -DCMAKE_INSTALL_PREFIX=/opt/qt \ -DWITH_QT3=ON \ -DQT_LIBRARY_DIRS=/opt/qt/lib \ -DCMAKE_SKIP_RPATH=ON || return 1 make I have run memtest86+ (for hours, through all tests/passes for 2 complete cycles and there are no problems) So if I understand what you need, you need me to build kdelibs with 4.5.2 to the point of failure with? cmake ../ \ -DCMAKE_C_COMPILER="/usr/bin/gcc -save-temps" \ -DCMAKE_CXX_COMPILER="/usr/bin/g++ -save-temps" \ Then I need to attach the precompiled sources -- which if I'm doing an out of source build in a temporary kdebase/src directory are which files? Are the precompiled sources going to end up in the kdebase/src/kcontrol/iccconfig directory -or- do you need the entire kdebase/src directory? I'm happy to get you anything that you need, but as I mentioned, this is the first possible compiler error I've run into. I want to do my part and get you everything that is needed so we can either rule-in or rule-out a gcc issue, but I just need a bit of explanation of what "what you need" is. I obviously misunderstood what the precompiled sources were, but I'm happy to go rebuild with -save-temps. I just need to know if simply adding -save-temps to the gcc flags will do it?
(In reply to comment #4) > > So if I understand what you need, you need me to build kdelibs with 4.5.2 to > the point of failure with? > > cmake ../ \ > -DCMAKE_C_COMPILER="/usr/bin/gcc -save-temps" \ > -DCMAKE_CXX_COMPILER="/usr/bin/g++ -save-temps" \ No, you can just run it to the point of failure, then repeat the command that failed, adding -save-temps. You don't need to use -save-temps for everything. > Then I need to attach the precompiled sources -- which if I'm doing an out of > source build in a temporary kdebase/src directory are which files? Are the > precompiled sources going to end up in the kdebase/src/kcontrol/iccconfig > directory -or- do you need the entire kdebase/src directory? Please don't send the whole directory. Just generate the preprocessed file for the one source file that fails to compile, and send us that preprocessed file, the one with a .ii extension. > I'm happy to get you anything that you need, but as I mentioned, this is the > first possible compiler error I've run into. I want to do my part and get you > everything that is needed so we can either rule-in or rule-out a gcc issue, but > I just need a bit of explanation of what "what you need" is. I obviously > misunderstood what the precompiled sources were, but I'm happy to go rebuild > with -save-temps. I just need to know if simply adding -save-temps to the gcc > flags will do it? Yes, but only do it for the gcc command that fails. We don't want dozens of preprocessed files for the things that compile ok, that's no use to anyone.
iccconfig.cpp:289 looks like: KRandrSimpleAPI *randrsimple = new KRandrSimpleAPI::KRandrSimpleAPI(); That code is invalid, gcc 4.5 is correct to reject it. It should be: KRandrSimpleAPI *randrsimple = new KRandrSimpleAPI();
the code can be reduced to struct S { }; int main() { S* p = new S::S(); } which is rejected too. The Trinity code needs to be fixed as suggested above, doing that will work with all versions of GCC (and other compilers)
Ok, I managed to generate iccconfig.ii and it is too big to attach. I have made it available on my site: http://www.3111skyline.com/dl/dt/trinity/errors/iccconfig-452/iccconfig.ii The whole build dir for iccconfig is there too: http://www.3111skyline.com/dl/dt/trinity/errors/iccconfig-452/
> I managed to generate iccconfig.ii and it is too big to attach. I have made it > available on my site: > > http://www.3111skyline.com/dl/dt/trinity/errors/iccconfig-452/iccconfig.ii zip/gzip/bzip2 is your friend.
As I said, GCC's behaviour was changed intentionally, for Bug 11764, to conform to a defect report against the C++ standard, DR 147 Jason, does DR 318 mean G++ should accept this, because the constructor is not an acceptable lookup result? struct S { }; S* p = new S::S();
Created attachment 23342 [details] iccconfig.ii (bzip2) Eric, Sorry for not zipping it and attaching it. When I originally tried to post it, the Create New Attachment page just said to include a link to it. I've attached it now for completeness (even though you probably don't need it now). Thank you all for your help and input.
(In reply to comment #10) > Jason, does DR 318 mean G++ should accept this, because the constructor is not > an acceptable lookup result? > struct S { }; > S* p = new S::S(); I suppose it does.
Actually, I think it's unclear. 318 had to do with elaborated type specifiers, for which we explicitly say that the lookup is done "ignoring any non-type names that have been declared."
(In reply to comment #10) > struct S { }; > S* p = new S::S(); EDG 4.0-4.3 all reject this as well.
Other folks on the committee agree that this is ill-formed, so I'm going to close the PR.