[Bug c/37384] New: Assembler error message when building vlc-0.9.1
When building version 0.9.0 or 0.9.1 of the videolan client application with gcc-4.3.2 or the 20080904 snapshot of version 4.3 I get the following error: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -DSYS_LINUX -D_FILE_OFFSET_BITS=64 -D__USE_UNIX98 -D_LARGEFILE64_SOURCE -D_REENTRANT -D_THREAD_SAFE -DHAVE_RELEASE -D__LIBVLC__ -I../src/misc -O2 -ffast-math -funroll-loops -mtune=pentium2 -fomit-frame-pointer -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DMODULE_STRING=\"main\" -DLOCALEDIR=\"/usr/share/locale\" -DSYSCONFDIR=\"/usr/etc\" -DDATA_PATH=\"/usr/share/vlc\" -DLIBDIR=\"/usr/lib\" -DPLUGIN_PATH=\"/usr/lib/vlc\" -I/usr/X11/include -Wall -Wextra -Wsign-compare -Wundef -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wvolatile-register-var -MT libvlccore_la-libvlc-module.lo -MD -MP -MF .deps/libvlccore_la-libvlc-module.Tpo -c libvlc-module.c -fPIC -DPIC -o .libs/libvlccore_la-libvlc-module.o /tmp/ccaXA1Ec.s: Assembler messages: /tmp/ccaXA1Ec.s:2537: Error: symbol `pread64' is already defined make[4]: *** [libvlccore_la-libvlc.lo] Error 1 make[4]: *** Waiting for unfinished jobs /tmp/ccWiBHlk.s: Assembler messages: /tmp/ccWiBHlk.s:12905: Error: symbol `pread64' is already defined make[4]: *** [libvlccore_la-libvlc-module.lo] Error 1 Both versions of gcc were configured as follows: $ gcc -v Using built-in specs. Target: i386-pc-linux Configured with: ../configure --prefix=/usr --infodir=/usr/info --mandir=/usr/man --enable-shared --disable-static --with-system-zlib --enable-threads=posix --enable-haifa --enable-languages=c,c++ --enable-long-long --enable-namespaces --enable-multilib --with-gnu-as --with-gnu-ld --with-system-zlib --without-x --disable-werror --disable-checking --enable-__cxa_atexit --disable-nls --without-included-gettext i386-pc-linux Thread model: posix gcc version 4.3.3 20080904 (prerelease) (GCC) The application builds successfully with gcc-4.2.5-20080820 and gcc-3.4.6. It also builds successfully if I omit the -O2 argument. I'll attach the preprocessed file that triggers the problem in a moment or two. -- Summary: Assembler error message when building vlc-0.9.1 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris2553 at googlemail dot com GCC build triplet: i386-pc-linux GCC host triplet: i386-pc-linux GCC target triplet: i386-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37384
[Bug c/37384] Assembler error message when building vlc-0.9.1
--- Comment #1 from chris2553 at googlemail dot com 2008-09-05 14:54 --- Created an attachment (id=16233) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16233&action=view) Preprocessed file that triggers the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37384
[Bug c/37384] Assembler error message when building vlc-0.9.1
--- Comment #5 from chris2553 at googlemail dot com 2008-09-09 17:50 --- Subject: Re: Assembler error message when building vlc-0.9.1 On Saturday 06 September 2008, pinskia at gcc dot gnu dot org wrote: > --- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-06 21:39 > --- This code is invalid and is caused by changing C99/GNU99 extern > inline to be correct to what C99 says. > Yes, I was trying to build against glibc-2.5. An upgrade to 2.7 had fixed the build. Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37384
[Bug c/41955] New: ICE compiling today's linux kernel git snapshot
Trying to build today's linux kernel development snapshot with gcc-4.4-20091103
snapshot, I get:
CC [M] fs/ext4/mballoc.o
CC [M] fs/fat/namei_msdos.o
fs/ext4/mballoc.c: In function 'ext4_mb_add_groupinfo':
fs/ext4/mballoc.c:2230: 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]: *** [fs/ext4/mballoc.o] Error 1
make[1]: *** [fs/ext4] Error 2
The build completes successfully when I revert to the 20091027 snapshot of gcc.
I have to go to out now so just a teads up to start with. I will get more
diagnostics tomorrow.
--
Summary: ICE compiling today's linux kernel git snapshot
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris2553 at googlemail dot com
GCC build triplet: i386-pc-linux
GCC host triplet: i386-pc-linux
GCC target triplet: i386-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41955
[Bug c/61215] New: ICE building wine-1.7.19 with gcc-4.9-20140514
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61215 Bug ID: 61215 Summary: ICE building wine-1.7.19 with gcc-4.9-20140514 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chris2553 at googlemail dot com Created attachment 32815 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32815&action=edit Preprcessed source file I've bumped into an ICE when building wine-1.7.19 with gcc-4.9-20140514. The build wine completes successfully with gcc-4.8-20140514. My system is a 32 bit user space running on a 64 bit kernel built from the latest 3.15.0 development sources. The hardware is a Fujitsu Lifebook AH531 laptop with 8GB RAM. The gcc build is configured with: --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=i386-pc-linux-gnu --infodir=/usr/info --mandir=/usr/man --enable-shared --disable-static --with-system-zlib --enable-threads=posix --enable-haifa --enable-languages=c,c++ --enable-long-long --enable-namespaces --enable-multilib --with-gnu-as --with-gnu-ld --with-system-zlib --without-x --disable-werror --disable-checking --enable-__cxa_atexit --disable-nls --without-included-gettext i386-pc-linux The command that triggers the ICE is: gcc -c -o schedsvc.o schedsvc.c -I. -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -fno-omit-frame-pointer -O3 -march=i686 -fno-omit-frame-pointer The compiler output is: schedsvc.c: In function 'SchRpcGetInstanceInfo': schedsvc.c:613:1: 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. The preprocessed file (compressed with xz) is attached.
[Bug c/61215] ICE building wine-1.7.19 with gcc-4.9-20140514
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61215 Chris Clayton changed: What|Removed |Added CC||chris2553 at googlemail dot com Known to work||4.8.3 Known to fail||4.9.1 --- Comment #1 from Chris Clayton --- Correction: successful build was with gcc-4.8-20140515
[Bug rtl-optimization/61215] [4.9/4.10 Regression] ICE in gen_add2_insn, at optabs.c:4718 when building wine-1.7.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61215 --- Comment #7 from Chris Clayton --- I can confirm that with Vladimir's patch applied to gcc-4.9-20140521, wine-1.7.19 now compiles successfully. Thanks everyone.
[Bug c++/62224] New: Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224 Bug ID: 62224 Summary: Possible regression in gcc-4.9-20140820 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: chris2553 at googlemail dot com Building qt-creator-3.2.0 with this week's 4.9.2 (21040820) snapshot fails. Building it with last week's 4.9.2 (20140813) snapshot succeeds. My system is a 32 bit user space running on a 64 bit 3.16.1 kernel built from source. The hardware is a Fujitsu Lifebook AH531 laptop with 8GB RAM. The gcc build is configured with: --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=i386-pc-linux-gnu --infodir=/usr/info --mandir=/usr/man --enable-shared --disable-static --with-system-zlib --enable-threads=posix --enable-haifa --enable-languages=c,c++ --enable-long-long --enable-namespaces --enable-multilib --with-gnu-as --with-gnu-ld --with-system-zlib --without-x --disable-werror --disable-checking --enable-__cxa_atexit --disable-nls --without-included-gettext i386-pc-linux The compiler output is: cd cppeditor/ && make -f Makefile make[3]: Entering directory '/home/chris/rpm/BUILD/qt-creator-opensource-src-3.2.0/qt-creator-3.2.0-build/src/plugins/cppeditor' rm -f libCppEditor.so g++ -Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/..' -Wl,--no-undefined -Wl,-O1 -shared -Wl,-soname,libCppEditor.so -o libCppEditor.so .obj/release-shared/cppautocompleter.o .obj/release-shared/cppcanonicalsymbol.o .obj/release-shared/cppclasswizard.o .obj/release-shared/cppcodemodelinspectordialog.o .obj/release-shared/cppdocumentationcommenthelper.o .obj/release-shared/cppeditor.o .obj/release-shared/cppeditordocument.o .obj/release-shared/cppeditoroutline.o .obj/release-shared/cppeditorplugin.o .obj/release-shared/cppelementevaluator.o .obj/release-shared/cppfilewizard.o .obj/release-shared/cppfollowsymbolundercursor.o .obj/release-shared/cppfunctiondecldeflink.o .obj/release-shared/cpphighlighter.o .obj/release-shared/cpphoverhandler.o .obj/release-shared/cppincludehierarchy.o .obj/release-shared/cppincludehierarchyitem.o .obj/release-shared/cppincludehierarchymodel.o .obj/release-shared/cppincludehierarchytreeview.o .obj/release-shared/cppinsertvirtualmethods.o .obj/release-shared/cpplocalrenaming.o .obj/release-shared/cppoutline.o .obj/release-shared/cpppreprocessordialog.o .obj/release-shared/cppquickfix.o .obj/release-shared/cppquickfixassistant.o .obj/release-shared/cppquickfixes.o .obj/release-shared/cppsnippetprovider.o .obj/release-shared/cpptypehierarchy.o .obj/release-shared/cppvirtualfunctionassistprovider.o .obj/release-shared/cppvirtualfunctionproposalitem.o .obj/release-shared/moc_cppclasswizard.o .obj/release-shared/moc_cppcodemodelinspectordialog.o .obj/release-shared/moc_cppdocumentationcommenthelper.o .obj/release-shared/moc_cppeditor.o .obj/release-shared/moc_cppeditordocument.o .obj/release-shared/moc_cppeditoroutline.o .obj/release-shared/moc_cppeditorplugin.o .obj/release-shared/moc_cppfilewizard.o .obj/release-shared/moc_cppfunctiondecldeflink.o .obj/release-shared/moc_cpphighlighter.o .obj/release-shared/moc_cpphoverhandler.o .obj/release-shared/moc_cppincludehierarchy.o .obj/release-shared/moc_cppincludehierarchymodel.o .obj/release-shared/moc_cppinsertvirtualmethods.o .obj/release-shared/moc_cpplocalrenaming.o .obj/release-shared/moc_cppoutline.o .obj/release-shared/moc_cpppreprocessordialog.o .obj/release-shared/moc_cppquickfix.o .obj/release-shared/moc_cpptypehierarchy.o .obj/release-shared/qrc_cppeditor.o -L/home/chris/rpm/BUILD/qt-creator-opensource-src-3.2.0/qt-creator-3.2.0-build/lib/qtcreator -L/home/chris/rpm/BUILD/qt-creator-opensource-src-3.2.0/qt-creator-3.2.0-build/lib/qtcreator/plugins -lTextEditor -lCore -lCppTools -lProjectExplorer -lCPlusPlus -lAggregation -lExtensionSystem -lQtcSsh -lUtils -lLanguageUtils -lQtGui -lQtNetwork -lQtCore -lpthread .obj/release-shared/cppcodemodelinspectordialog.o: In function `CppEditor::Internal::CppCodeModelInspectorDialog::refresh()': cppcodemodelinspectordialog.cpp:(.text+0x79bd): undefined reference to `CppTools::Internal::CppModelManager::ensureUpdated()' cppcodemodelinspectordialog.cpp:(.text+0x79fc): undefined reference to `CppTools::Internal::CppModelManager::ensureUpdated()' .obj/release-shared/cppcodemodelinspectordialog.o: In function `CppTools::Internal::CppModelManager::definedMacros()': cppcodemodelinspectordialog.cpp:(.text._ZN8CppTools8Internal15CppModelManager13definedMacrosEv[_ZN8CppTools8Internal15CppModelManager13definedMacrosEv]+0x26): undefined reference to `CppTools::Internal::CppModelManager::ensureUpdated()' .obj/release-shared/cppcodemodelinspectordialog.o: In function `CppTools::Internal::CppModelManager::headerPaths()': cppcodemodelinspectordia
[Bug c++/62224] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224 --- Comment #1 from Chris Clayton --- Created attachment 33377 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33377&action=edit Preprocessed source file ETOOBIG on uncompressed attachment. Now compressed with xz.
[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224 --- Comment #3 from Chris Clayton --- Yes, the preprocessed file is the one providing the unresolved references. It surely won't be a surprise to anyone to here that the same failure occurs when building with yesterday's 4.9 snapshot 4.9-20140827.
[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224
--- Comment #5 from Chris Clayton ---
I reverted the code change from r214208 with the following patch:
--- gcc-4.9-20140827-orig/gcc/cp/decl2.c2014-08-20 02:54:40.0
+0100
+++ gcc-4.9-20140827/gcc/cp/decl2.c 2014-09-01 21:07:29.799905722 +0100
@@ -1934,11 +1934,6 @@ decl_needed_p (tree decl)
if (flag_keep_inline_dllexport
&& lookup_attribute ("dllexport", DECL_ATTRIBUTES (decl)))
return true;
- /* Virtual functions might be needed for devirtualization. */
- if (flag_devirtualize
- && TREE_CODE (decl) == FUNCTION_DECL
- && DECL_VIRTUAL_P (decl))
-return true;
/* Otherwise, DECL does not need to be emitted -- yet. A subsequent
reference to DECL might cause it to be emitted later. */
return false;
With this patch applied to gcc-4.9-20140827, I can now build qt-creator-3.2.0
successfully.
[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224 --- Comment #7 from Chris Clayton --- Created attachment 33439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33439&action=edit Pre-processed cppcodemodelinspectordialog cppcodemodelinspectordialog.ii compressed with xz.
[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224
--- Comment #9 from Chris Clayton ---
That seems odd to me, although I'm happy to be told I'm wrong. I base this on
the fact that reverting the code change from r214208 permits a successful
build. MoreOver, in both the failed and sucessful builds, ensureUpdated is
present in cppmodelmanager.o and that is linked into libCppTools.so as can be
seen by:
[chris:~/rpm/build/qt-creator-opensource-src-3.2.0-fail/qt-creator-3.2.0-build]$
nm lib/qtcreator/plugins/libCppTools.so | grep ensureUpdated
000af430 t _ZN8CppTools8Internal15CppModelManager13ensureUpdatedEv
[chris:~/rpm/build/qt-creator-opensource-src-3.2.0-fail/qt-creator-3.2.0-build]$
cd ~/rpm/build/qt-creator-opensource-src-3.2.0/qt-creator-3.2.0-build
[chris:~/rpm/build/qt-creator-opensource-src-3.2.0/qt-creator-3.2.0-build]$ nm
lib/qtcreator/plugins/libCppTools.so | grep ensureUpdated
000af640 t _ZN8CppTools8Internal15CppModelManager13ensureUpdatedEv
cppmodelmanager.0 is listed (in Makefile) as an object to be included in the
link of libCppTools.so in both builds.
I don't know whether it will be of any help, but I've diffed cppmodelmanager.ii
produced in the two builds and the output is:
--- cppmodelmanager.ii.good 2014-09-02 21:25:02.559799184 +0100
+++ cppmodelmanager.ii.fail 2014-08-22 08:27:06.0 +0100
@@ -18581,23 +18581,7 @@ namespace std __attribute__ ((__visibili
inline basic_istream<_CharT, _Traits>&
getline(basic_istream<_CharT, _Traits>& __is,
basic_string<_CharT, _Traits, _Alloc>& __str)
-{ return std::getline(__is, __str, __is.widen('\n')); }
-
-
-
- template
-inline basic_istream<_CharT, _Traits>&
-getline(basic_istream<_CharT, _Traits>&& __is,
- basic_string<_CharT, _Traits, _Alloc>& __str, _CharT __delim)
-{ return std::getline(__is, __str, __delim); }
-
-
- template
-inline basic_istream<_CharT, _Traits>&
-getline(basic_istream<_CharT, _Traits>&& __is,
- basic_string<_CharT, _Traits, _Alloc>& __str)
-{ return std::getline(__is, __str); }
-
+{ return getline(__is, __str, __is.widen('\n')); }
template<>
basic_istream&
@@ -19695,7 +19679,7 @@ namespace __gnu_cxx __attribute__ ((__vi
}
-# 2851 "/usr/include/c++/4.9.2/bits/basic_string.h" 2 3
+# 2835 "/usr/include/c++/4.9.2/bits/basic_string.h" 2 3
namespace std __attribute__ ((__visibility__ ("default")))
{
@@ -20103,7 +20087,7 @@ namespace std __attribute__ ((__visibili
}
-# 3069 "/usr/include/c++/4.9.2/bits/basic_string.h" 2 3
+# 3053 "/usr/include/c++/4.9.2/bits/basic_string.h" 2 3
namespace std __attribute__ ((__visibility__ ("default")))
{
@@ -20174,7 +20158,7 @@ namespace std __attribute__ ((__visibili
template<>
struct __is_fast_hash> : std::false_type
{ };
-# 3173 "/usr/include/c++/4.9.2/bits/basic_string.h" 3
+# 3157 "/usr/include/c++/4.9.2/bits/basic_string.h" 3
}
# 53 "/usr/include/c++/4.9.2/string" 2 3
[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224 --- Comment #12 from Chris Clayton --- Sorry, you'll have to stick with me here while a figure out what that means. I think you are saying that prior to r214208, the symbols definedMacros() and headerPaths() were present but effectively no-ops. Post r214208 they now "contain" operations including calls to ensureUpdated(). Given that the symbol for ensureUpdated() appears to be present in libCppTools.so (along with the symbols for its two post-r214208 callers), does that suggest a problem with the linker, which is /usr/bin/ld from the latest version (2.24) of binutils? Or could it be anything to do with my system being a 32bit userspace on a 64bit kernel? I usually build packages as rpms and have the rpm binary wrapped in a script which uses prefixes the call to the actual rpm binary with "setarch i386". I've been careful whilst investigated this problem to make sure that I prefix calls to qmake and make with "setarch i386". I've built loads and loads of packages with this setup (including gcc). I'm just trying to figure out the next port of call with this problem. I note that the Debian folks have a bug logged but seem to be waiting on resolution via this bug report - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759862.
[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224 --- Comment #17 from Chris Clayton --- I can confirm that with Jason's code changes (referenced in comment 15) to gcc/cp/decl2.c and gcc/gimple-fold.c, the resultant compiler successfully builds qt-creator-3.2.0. Thanks Jason.
[Bug c++/42773] New: ICE with g++ from 4.4.3 20100112 (prerelease)
The summary says it all.
Diagnostics:
if /bin/sh ../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I.. -I../lib/kofficeui -I../lib/kofficeui -I../lib/kofficecore
-I../lib/kofficecore -I../lib/store -I../lib/store -I../lib/kwmf -I../lib/kwmf
-I../lib/kopalette -I../lib/kopalette -I../lib/kotext -I../lib/kotext
-I../lib/interfaces -I./tests -Idialogs -I../interfaces -I../kchart/kdchart
-I/opt/kde3/include -I/usr/lib/qt3/include -I/usr/X11/include
-I/usr/include/python2.6 -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long
-Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts
-Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O3 -march=i686
-Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE
-DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION
-DHAVE_KNEWSTUFF -MT kspread_cell.lo -MD -MP -MF ".deps/kspread_cell.Tpo" -c
-o kspread_cell.lo kspread_cell.cc; \
then mv -f ".deps/kspread_cell.Tpo" ".deps/kspread_cell.Plo"; else rm
-f ".deps/kspread_cell.Tpo"; exit 1; fi
kspread_cell.cc: In member function 'void KSpread::Cell::setOutputText()':
kspread_cell.cc:1611: warning: suggest parentheses around '&&' within '||'
kspread_cell.cc: In member function 'QValueList
KSpread::Cell::obscuringCells() const':
kspread_cell.cc:908: 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[1]: *** [kspread_cell.lo] Error 1
[chris:~]$ gcc -v
Using built-in specs.
Target: i386-pc-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/info
--mandir=/usr/man --enable-shared --disable-static --with-system-zlib
--enable-threads=posix --enable-haifa --enable-languages=c,c++
--enable-long-long --enable-namespaces --enable-multilib --with-gnu-as
--with-gnu-ld --with-system-zlib --without-x --disable-werror
--disable-checking --enable-__cxa_atexit --disable-nls
--without-included-gettext i386-pc-linux
Thread model: posix
gcc version 4.4.3 20100112 (prerelease) (GCC)
The only other compiler I currently have installed is gcc-3.4.6, and, for what
it's worth, that compiles the file without error.
Thanks
--
Summary: ICE with g++ from 4.4.3 20100112 (prerelease)
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris2553 at googlemail dot com
GCC build triplet: i386-pc-linux
GCC host triplet: i386-pc-linux
GCC target triplet: i386-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42773
[Bug c++/42773] ICE with g++ from 4.4.3 20100112 (prerelease)
--- Comment #1 from chris2553 at googlemail dot com 2010-01-17 10:29 --- Created an attachment (id=19631) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19631&action=view) Preprocessed input Had to gzip the file because at 1.1Mb it was bounced by bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42773
[Bug tree-optimization/42773] [4.4 Regression] ICE with g++ from 4.4.3 20100112 (prerelease)
--- Comment #7 from chris2553 at googlemail dot com 2010-01-18 22:24 --- I can confirm that the patch at comment 4 has fixed the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42773
[Bug c++/30376] New: aspell-0.60.5 fails to build with -O3 on gcc-4.1.2 20061222 (prerelease)
I get the following failure trying to build aspell-0.60.5 with gcc 4.1.2
20061222 (prerelease):
bin/sh ./libtool --tag=CXX --mode=link i386-pc-linux-g++ -O3 -march=i386
-fno-strength-reduce -fno-exceptions -fno-exceptions -s -o aspell
prog/aspell.o prog/check_funs.o prog/checker_string.o libaspell.la -lncurses
-ldl -ldl
i386-pc-linux-g++ -O3 -march=i386 -fno-strength-reduce -fno-exceptions
-fno-exceptions -s -o .libs/aspell prog/aspell.o prog/check_funs.o
prog/checker_string.o ./.libs/libaspell.so -L/usr/lib /usr/lib/libintl.so
/usr/lib/libstdc++.so -lncurses -ldl
./.libs/libaspell.so: undefined reference to
`acommon::HashTable::erase(char const* const&)'
collect2: ld returned 1 exit status
make[1]: *** [aspell] Error 1
make[1]: Leaving directory `/home/users/chris/rpm/BUILD/aspell-0.60.5'
make: *** [all-recursive] Error 1
If I change the optimisation to -O2, the build completes, so I guess I have a
GCC problem.
Happy to try patches and provide additional diagnostics.
--
Summary: aspell-0.60.5 fails to build with -O3 on gcc-4.1.2
20061222 (prerelease)
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris2553 at googlemail dot com
GCC build triplet: 386-pc-linux
GCC host triplet: i386-pc-linux
GCC target triplet: 386-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30376
[Bug c++/30376] aspell-0.60.5 fails to build with -O3 on gcc-4.1.2 20061222 (prerelease)
--- Comment #2 from chris2553 at googlemail dot com 2007-01-05 05:56 --- Subject: Re: aspell-0.60.5 fails to build with -O3 on gcc-4.1.2 20061222 (prerelease) Thanks for the reply. On Thursday 04 January 2007 22:25, pinskia at gcc dot gnu dot org wrote: > > --- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-04 22:25 > --- > > If I change the optimisation to -O2, the build completes, so I guess I have > > a > > GCC problem. > > No, not always. In fact what most likely happening is something is being > inlined (because of -O3) which was not before and now you get a reference to > something which was not being referenced before. > Sorry, I simply don't understand that. The build completes with -O2 but not with -O3. I'm light years away from even a basic knowledge of compiler technology, but I would have thought that if the compiler inlined something, there would be no reference for the linker to subsequently resolve. But, like I say, I'm light years... Anyway, since filing the bug report, I've built the package on my laptop, which has GCC 3.3.6 installed. In this case the build completes with -O3 optimisation. > I think the only way to fix this is to dig into the sources of aspell and see > if this is the case. We cannot help that much except maybe do the compile for > you. If I was a C++ programmer, I might just do that. Unfortunately, I'm not! I did have a dabble with Borland C++ many years ago, but since then templates (and similar stuff) have been introduced and made the language too complex for me to be bothered.. > > It might be worth filing a bug with aspell and seeing what they can do with > it. > > That was my first port of call, but I got no response. (http://lists.gnu.org/archive/html/aspell-user/2006-12/msg00012.html) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30376
[Bug c/97953] New: ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
Bug ID: 97953
Summary: ICE (segfault) during GIMPLE pass: loopdone compiling
libgcc/config/libbid/bid128_fma.c:190:1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chris2553 at googlemail dot com
Target Milestone: ---
Building 11-20201122 (with gcc-10-20201121 or gcc-10-20201114) results in an
ICE as follows:
/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu/./gcc/xgcc
-B/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include
-fno-checking -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes
-Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem
./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80
-DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc
-I../../../gcc-11-20201122/libgcc -I../../../gcc-11-20201122/libgcc/.
-I../../../gcc-11-20201122/libgcc/../gcc
-I../../../gcc-11-20201122/libgcc/../include
-I../../../gcc-11-20201122/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS -DUSE_TLS -o bid128_fma.o -MT bid128_fma.o -MD -MP -MF
bid128_fma.dep -c ../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c
during GIMPLE pass: loopdone
../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c: In function
'nr_digits256':
../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c:190:1: internal
compiler error: Segmentation fault
190 | nr_digits256 (UINT256 R256) {
| ^~~~
A log of the full build (using rpmbuild) and the preprocessed source are
attached.
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #1 from Chris Clayton --- Created attachment 49611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49611&action=edit Preprocessed source
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #2 from Chris Clayton --- Created attachment 49612 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49612&action=edit Full build log
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #4 from Chris Clayton --- I've done a few more builds of snapshot releases of gcc-11. Using with gcc-10-20201122, I get the ICE building 11-2020115, but 11-20201108 and 20201101 both build successfully.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #7 from Chris Clayton --- Yes, Richard's correct. I'm building from snapshot releases. That's why I used the term "snapshot releases" in comment 4. I've cloned git://gcc.gnu.org/git/gcc.git and am bisecting between b642fca1c31b2e2175e0860daf32b4ee0d918085 (11-20201108) and c746fc40f4ec8cfc1092efd49d567751858d2099 (11-20201115). I'm not 100% sure this is correct because I'm anything but a git expert and I've never come across a tree that didn't have branches for different strands of development (e.g gcc-10 gcc-11). git bisect start... reported that there were only 7 commits and that feels right, so I'll blunder on until someone tells me I'm doing this wrong (an, hopefully, how I should be doing it)
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #8 from Chris Clayton --- Sorry, my last comment contains an error. git bisect start... reported 7 bisections would be needed not that there were only 7 commits.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #11 from Chris Clayton --- I've finished the bisect and landed at: [chris:~/scratch/gcc-ICE/gcc]$ git bisect good bd87cc14ebdb6789e067fb1828d5808407c308b3 is the first bad commit commit bd87cc14ebdb6789e067fb1828d5808407c308b3 Author: Richard Biener Date: Wed Nov 11 11:51:59 2020 +0100 tree-optimization/97623 - Avoid PRE hoist insertion iteration The recent previous change in this area limited hoist insertion iteration via a param but the following is IMHO better since we are not really interested in PRE opportunities exposed by hoisting but only the other way around. So this moves hoist insertion after PRE iteration finished and removes hoist insertion iteration alltogether. 2020-11-11 Richard Biener PR tree-optimization/97623 * params.opt (-param=max-pre-hoist-insert-iterations): Remove again. * doc/invoke.texi (max-pre-hoist-insert-iterations): Likewise. * tree-ssa-pre.c (insert): Move hoist insertion after PRE insertion iteration and do not iterate it. * gcc.dg/tree-ssa/ssa-hoist-3.c: Adjust. * gcc.dg/tree-ssa/ssa-hoist-7.c: Likewise. * gcc.dg/tree-ssa/ssa-pre-30.c: Likewise. gcc/doc/invoke.texi | 5 - gcc/params.opt | 4 gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-3.c | 2 +- gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-7.c | 4 ++-- gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-30.c | 2 +- gcc/tree-ssa-pre.c | 34 +++-- 6 files changed, 26 insertions(+), 25 deletions(-) I've also confirmed the outcome. A build with this commit at HEAD fails with the ICE. A build with the commits parent at HEAD succeeds. I'll attach the bisect log in a few minutes.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #12 from Chris Clayton --- Created attachment 49622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49622&action=edit git bisect log
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #13 from Chris Clayton --- (In reply to Martin Liška from comment #9) > Ok, so the question is: does it reproduce with the current master or now? Short answer: Yes, it does. A build done this morning (after pulling the latest changes into the tree I cloned yesterday) fails with the same ICE error messages.
[Bug tree-optimization/97953] [8/9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #22 from Chris Clayton --- I've applied Richard's patch to the 20201122 snapshot and can happily report that the build now completes successfully. My thanks to Martin and Richard.
[Bug c++/105256] New: ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
Bug ID: 105256
Summary: ICE compiling firefox-99
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chris2553 at googlemail dot com
Target Milestone: ---
I get the following ICE bump when compiling firefox-99.0 (and 99.0.1) with a
gcc installation built from the gcc-11-20220409 snapshot. The same ICE occurs
with gcc-11-20220402.
30:42.01 In file included from Unified_cpp_layout_style2.cpp:92:
30:42.01 /home/chris/rpm/BUILD/firefox-99.0.1/layout/style/PreferenceSheet.cpp:
In member function 'void mozilla::PreferenceSheet::Prefs::Load(bool)':
30:42.01
/home/chris/rpm/BUILD/firefox-99.0.1/layout/style/PreferenceSheet.cpp:181:12:
internal compiler error: Segmentation fault
30:42.01 181 | *this = {};
30:42.01 |^
30:42.03 0x16b0e03 diagnostic_impl(rich_location*, diagnostic_metadata const*,
int, char const*, __va_list_tag (*) [1], diagnostic_t)
30:42.03???:0
30:42.03 0x16b1247 internal_error(char const*, ...)
30:42.03???:0
30:42.03 0xc8edbf crash_signal(int)
30:42.03???:0
30:42.03 0x8674f3 ggc_free(void*)
30:42.03???:0
30:42.04 0x62a075 gimplify_asm_expr(tree_node**, gimple**, gimple**) [clone
.isra.0] [clone .cold]
30:42.04???:0
30:42.04 Please submit a full bug report,
30:42.04 with preprocessed source if appropriate.
30:42.04 Please include the complete backtrace with any bug report.
30:42.04 See <https://gcc.gnu.org/bugs/> for instructions.
30:42.11 gmake[4]: ***
[/home/chris/rpm/BUILD/firefox-99.0.1/config/rules.mk:660:
Unified_cpp_layout_style2.o] Error 1
30:42.11 gmake[3]: ***
[/home/chris/rpm/BUILD/firefox-99.0.1/config/recurse.mk:72:
layout/style/target-objects] Error 2
30:42.11 gmake[3]: *** Waiting for unfinished jobs
The same build completes successfully with gcc-12-20220410 and with
gcc-10-20220408.
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #2 from Chris Clayton --- Created attachment 52802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52802&action=edit First requested file
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #3 from Chris Clayton --- Created attachment 52803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52803&action=edit Second requested file - part1
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #4 from Chris Clayton --- Created attachment 52804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52804&action=edit Second Requested file - part2
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #5 from Chris Clayton --- The .ii file was huge so I've had to split it and then compress the parts
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #6 from Chris Clayton --- I'm struggling to get the compiler command line. The build system is wrapped in a build tool called mach and I'm darned if I can find an argument that will cause it to report the command it is about to launch. The -verbose argument seems to have very little effect on the messages that are output as does the --log-file argument. Hey ho.
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #17 from Chris Clayton --- Created attachment 52810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52810&action=edit Compiler commands Finally got them by running running "ps ax" in a while true loop, grepping the output for the file name and writing any matches to a file. There must be an easier way!
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #24 from Chris Clayton --- I see the patch is for gcc-12. As I said in comment, I don't get the ICE with the latest gcc-12 snapshot, but is it worth me applying the patch to gcc-11 (with which I do get the ICE) and testing a build with that?
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #25 from Chris Clayton --- I went ahead and patched gcc-11-0220409 and with the resultant compiler have had two successful builds of firefox-99. I then reverted to the unpatched gcc and a build of firefox-99 failed with the same ICE that I reported in comment 1.
[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #33 from Chris Clayton --- On 20/04/2022 07:46, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 > > Jakub Jelinek changed: > >What|Removed |Added > > Summary|[9/10/11 Regression] ICE|[9/10 Regression] ICE >|compiling firefox-99|compiling firefox-99 > Status|NEW |ASSIGNED >Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot > gnu.org > > --- Comment #32 from Jakub Jelinek --- > Fixed for 11.3 as well. and I've successfully built firefox-99.0.1 using 11.3-RC with this patch applied. Thanks Jakub. >
[Bug c/106172] New: Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 Bug ID: 106172 Summary: Multiple ICEs building gcc-13 with gcc-12 Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chris2553 at googlemail dot com Target Milestone: --- Created attachment 53246 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53246&action=edit GCC diagnostics file 1 I'm trying to build the gcc-13-20220626 snapshot with the gcc-12-20220702 snapshot but get multiple ICEs. I got the same (or similar) bunch of ICE's last week trying to build gcc-13-20220626 with gcc-12-20220625, but didn't have time to get the diagnostics and report it last week) I've run the build again with the recommended -freport-bug added to CFLAGSand the files saved to /tmp/ are attached as is a file containing the text splat on the console when the ICEs happened.
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #1 from Chris Clayton --- Created attachment 53247 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53247&action=edit GCC diagnostics file 2
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #2 from Chris Clayton --- Created attachment 53248 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53248&action=edit GCC diagnostics file 3
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #3 from Chris Clayton --- Created attachment 53249 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53249&action=edit GCC diagnostics file 4
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #4 from Chris Clayton --- Created attachment 53250 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53250&action=edit GCC diagnostics file 5
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #5 from Chris Clayton --- Created attachment 53251 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53251&action=edit GCC diagnostics file 6
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #6 from Chris Clayton --- Created attachment 53252 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53252&action=edit GCC diagnostics file 7
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #7 from Chris Clayton --- Created attachment 53253 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53253&action=edit GCC diagnostics file 8
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #8 from Chris Clayton --- Created attachment 53254 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53254&action=edit GCC diagnostics file 9
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #9 from Chris Clayton --- Created attachment 53255 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53255&action=edit Error messages output to terminal
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #11 from Chris Clayton --- On 03/07/2022 12:00, sch...@linux-m68k.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > > --- Comment #10 from Andreas Schwab --- > How did you build the bootstrap compiler? > I assume that by bootstrap compiler you mean xgcc/xg++. If not, what is it? In any case, I didn't do anything in particular. As I understand it, the bootstrap compiler is built as an early step of the gcc build system so it will have been built with gcc-12-20220702.
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #12 from Chris Clayton --- I've just run the build again with gcc-11-20220701 and get the same set of ICEs. I've kept the files of diagnostics output by gcc and can provide them id they will be helpful.
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #15 from Chris Clayton --- On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > > Andrew Pinski changed: > >What|Removed |Added > > Status|UNCONFIRMED |WAITING > Ever confirmed|0 |1 >Last reconfirmed||2022-07-03 > > --- Comment #14 from Andrew Pinski --- >> make[2]: *** [Makefile:20255: all-stage2-target-libgcc] Error 2 >> make[2]: Leaving directory >> '/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu' >> make[1]: *** [Makefile:25739: stage2-bubble] Error 2 >> make[1]: Leaving directory >> '/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu' >> make: *** [Makefile:1072: all] Error 2 > > > Did you set any CFLAGS or STAGE1_CFLAGS (or CXXFLAGS) env? > What the above means is stage1 is being miscompiled. I build and manage packages with rpm. Through rpmbuild the default for CFLAGS is "-O2 -g". To that I add "-mindirect-branch=thunk" to build with retpoline enabled. > I Noticed you used --disable-checking, these days the default for releases is > --enable-checking=release rather than --disable-checking (slightly different > though). Is that likely to be the source of the problem? If not, I'll look into it when this problem is solved. > Another data point - I've just tried to build gcc-13-20220626 with gcc-10.4.0 and get the same batch of ICEs.
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #16 from Chris Clayton --- I've tried two further build of gcc-13 using gcc-12-20220702. The gcc-13-20220703 snapshot fails with the same ICEs but the 20220619 snapshot builds successfully. So we have 13-20220626 and 13-20220703 both fail but 13-20220619 succeeds.
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #17 from Chris Clayton --- I've cloned git://gcc.gnu.org/git/gcc.git and bisected between 13-20220626 (ff35dbc02092fbcd3d814fcd9fe8e871c3f741fd) and 13-20220619 (4390e7bfbc641a52c6192b448768dafdf4565527) as bad and good respectively. The result is: 8c99e307b20c502e55c425897fb3884ba8f05882 is the first bad commit commit 8c99e307b20c502e55c425897fb3884ba8f05882 Author: Aldy Hernandez Date: Sat Jun 25 18:58:02 2022 -0400 Convert DOM to use Ranger rather than EVRP [Jeff, this is the same patch I sent you last week with minor tweaks to the commit message.] [Despite the verbosity of the message, this is actually a pretty straightforward patch. It should've gone in last cycle, but there was a nagging regression I couldn't get to until after stage1 had closed.] There are 3 uses of EVRP in DOM that must be converted. Unfortunately, they need to be converted in one go, so further splitting of this patch would be problematic. There's nothing here earth shattering. It's all pretty obvious in retrospect, but I've added a short description of each use to aid in reviewing: * Convert evrp use in cprop to ranger. This is easy, as cprop in DOM was converted to the ranger API last cycle, so this is just a matter of using a ranger instead of an evrp_range_analyzer. * Convert evrp use in threader to ranger. The idea here is to use the hybrid approach we used for the initial VRP threader conversion last cycle. The DOM threader will continue using the forward threader infrastructure while continuing to query DOM data structures, and only if the conditional does not relsolve, using the ranger. This gives us the best of both worlds, and is a proven approach. Furthermore, as frange and prange come live in the next cycle, we can move away from the forward threader altogether, and just add another backward threader. This will not only remove the last use of the forward threader, but will allow us to remove at least 1 or 2 threader instances. * Convert conditional folding to use the method used by the ranger and evrp. Previously DOM was calling into the guts of simplify_using_ranges::vrp_visit_cond_stmt. The blessed way now is using fold_cond() which rewrites the conditional and edges automatically. When legacy is removed, simplify_using_ranges will be further cleaned up, and there will only be one entry point into simplifying a statement. * DOM was setting global ranges determined from unreachable edges as a side-effect of using the evrp engine. We must handle these cases before nuking evrp, and DOM seems like a good fit. I've just moved the snippet to DOM, but it could live anywhere else we do a DOM walk. For the record, this is the case *vrp handled: : ... if (c_5(D) != 5) goto ; else goto ; : __builtin_unreachable (); : If M dominates all uses of c_5, we can set the global range of c_5 to [5,5]. I have tested on x86-64, pcc64le, and aarch64 Linux. I also ran threading benchmarks as well as performance benchmarks. DOM threads 1.56% more paths which ultimately yields a miniscule total increase of 0.03%. The conversion to ranger brings a 7.87% performance drop in DOM, which is a wash in overall compilation. This is in line with other replacements of legacy evrp with ranger. We handle a lot more cases. It's not free . There is a a regression on Wstringop-overflow-4.C which I'm planning on XFAILing. It's another variant of the usual middle-end false positives: having no ranges produces no warnings, but slightly refined ranges, or worse-- isolating specific problematic cases in the threader causes flare-ups. As an aside, as Richi has suggested, I think we should discuss restricting the threader's ability to thread highly unlikely paths. These cause no end of pain for middle-end warnings. However, I don't know if this would conflict with path isolation for things like null dereferencing. ISTR you were interested in this. BTW, I think the Wstringop-overflow-4.C test is problematic and I've attached my analysis. Basically the regression is caused by a bad interaction with the rounding/alignment that placement new has inlined into the IL. This happens for int16_r[] which the test is testing. Ranger can glean some range info, which causes DOM threading to isolate a path which causes a warning. ... I'll attach the bisect log shortly.
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #18 from Chris Clayton --- Created attachment 53256 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53256&action=edit git bisect log
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #19 from Chris Clayton --- Hi On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > > Andrew Pinski changed: > >What|Removed |Added > > Status|UNCONFIRMED |WAITING > Ever confirmed|0 |1 >Last reconfirmed||2022-07-03 > I some additional diagnostics (the result of a bisect) to the bugzilla report earlier this week. The first bad commit was 8c99e307b20. I've been busy since but have just checked out the first bad commit's parent commit (54a5f478487) and built with gcc-12-20220702. That build completed successfully.
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #20 from Chris Clayton --- On 08/07/2022 15:02, Chris Clayton wrote: > Hi > > On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 >> >> Andrew Pinski changed: >> >>What|Removed |Added >> >> Status|UNCONFIRMED |WAITING >> Ever confirmed|0 |1 >>Last reconfirmed||2022-07-03 >> > > I some additional diagnostics (the result of a bisect) to the bugzilla report > earlier this week. The first bad commit > was 8c99e307b20. > > I've been busy since but have just checked out the first bad commit's parent > commit (54a5f478487) and built with > gcc-12-20220702. That build completed successfully. As an update, I've just tried to build the gcc-13-20220717 snapshot using a compiler built with gcc-12-20220716 snapshot. The outcome is the same set of ICEs. I've also realised this morning that I forgot to add the author of the first bad coomit from the bisect that I reported the results of. So, al...@redhat.com added as recipient of this email. Aldy - the first bad commit from the bisect was 8c99e307b20c502e55c425897fb3884ba8f05882 (Convert DOM to use Ranger rather than EVRP). It seems to be involved in some way in a batch of ICEs I see when trying to build recent gcc-13 snapshots (20220626 and later) with recent gcc-12 snapshots. I aslo get the ICEs trying to build gcc-13 with a gcc-11 or gcc-10 compiler. The diagnostics I've collected are attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > >
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #23 from Chris Clayton --- On 18/07/2022 19:13, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > > Aldy Hernandez changed: > >What|Removed |Added > > CC||aldyh at gcc dot gnu.org > Status|WAITING |NEW > > --- Comment #21 from Aldy Hernandez --- > Confirmed on x86-64 with: ./configure --enable-languages=c,c++ > --enable-checking=no. > > Interestingly, --enable-checking=release works. > Yes, that build succeeds here too. I've had --disable-checking in the picture for at least 5 years, and it's not been a problem. I've built hundreds of gcc- snapshots using gcc- snapshots in that time. Anyway I can drop the checking option altogether because the documentation states that --enable-checking=release is the default. But I guess there is a problem that needs to be fixed albeit maybe not an urgent one. If anyone wants a fix testing, I'm more than happy to help, so just drop me an email. I'll put a comment in my rpm spec file to remind that I need to add the option back in. Thanks.
