[Bug c++/111974] internal error: Segmentation fault on Ubuntu 23.10 (x86-64) - compiling RefPerSys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111974 --- Comment #3 from Basile Starynkevitch --- This bug seems to have disappeared with a trunk GCC (GCC commit f32c1e1e96ffef) compiled from its source code /usr/local/bin/g++-trunk --version g++-trunk (GCC) 14.0.0 20231025 (experimental) Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. where the g++ trunk code has been configured then compiled using '../gcc/configure' '--enable-host-shared' '--program-suffix=-trunk' '--enable-debug' '--disable-bootstrap' 'CFLAGS=-O2 -g' 'CXXFLAGS=-O2 -g' '--enable-languages=c,c++,jit,lto'
[Bug c++/111974] internal error: Segmentation fault on Ubuntu 23.10 (x86-64) - compiling RefPerSys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111974 --- Comment #1 from Basile Starynkevitch --- To reproduce the GCC bug: rm -vf cmdrepl_rps.o make cmdrepl_rps.o
[Bug c++/111974] New: internal error: Segmentation fault on Ubuntu 23.10 (x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111974 Bug ID: 111974 Summary: internal error: Segmentation fault on Ubuntu 23.10 (x86-64) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: basile at starynkevitch dot net Target Milestone: --- I uploaded to refpersys.org/refpersys-gcc13bug-snapshot-25oct2023-git041d5d70aefd0.tar.bz2 a compressed tarball (29246912 bytes) of md5sum 6b1d2985ce86bd1718d05af3d93a84f9 RefPerSys is a GPLv3+ open source project for an inference engine. See http://refpersys.org/ for details. The code repository of RefPerSys is on gihtub. See the commit https://github.com/RefPerSys/RefPerSys/commit/041d5d70aefd047de4eb456432853beefffb4120 On Ubuntu 23.10 (x86-64 desktop with AMD Ryzen Threadripper 2970WX) this tarball is crashing the GCC 13.2 compiler with a reproducible GCC compiler bug. To reproduce, (using GNU make 4.3) run make cmdrepl_rps.o which crashes with rimski.x86_64 ~/RefPerSys 11:17 .0 % make cmdrepl_rps.o /usr/bin/time --append --format='%C : %S sys, %U user, %E elapsed; %M RSS' --output=_build.time g++-13 -std=gnu++17 -O1 -g3 -fPIC -Wall -Wextra -I. -I/usr/local/include -I/usr/include -I/usr/include/jsoncpp -I/usr/include/jsoncpp -I/usr/include/jsoncpp -I/usr/include/x86_64-linux-gnu -I/usr/local/include/ -DRPS_ARCH=\"x86_64\" -DRPS_HAVE_ARCH_x86_64 -DRPS_OPERSYS=\"GNU_Linux\" -DRPS_HAVE_OPERSYS_GNU_Linux -DRPS_GITID=\"041d5d70aefd047de4eb456432853beefffb4120+\" -DRPS_SHORTGITID=\"041d5d70aefd+\" -I/usr/src/Libs/lightning/include/lightning -std=gnu++17-c -o cmdrepl_rps.o cmdrepl_rps.cc cmdrepl_rps.cc:51:2: warning: #warning should declare rps_full_evaluate_repl_instance [-Wcpp] 51 | #warning should declare rps_full_evaluate_repl_instance | ^~~ cmdrepl_rps.cc:146:2: warning: #warning rps_full_evaluate_repl_expr should check that envob is an environment, with bindings and optional parent env [-Wcpp] 146 | #warning rps_full_evaluate_repl_expr should check that envob is an environment, with bindings and optional parent env | ^~~ cmdrepl_rps.cc:180:2: warning: #warning TODO: should probably define and call a rps_full_evaluate_repl_instance [-Wcpp] 180 | #warning TODO: should probably define and call a rps_full_evaluate_repl_instance | ^~~ cmdrepl_rps.cc:303:2: warning: #warning TODO: fixme evaluation of various repl_expression-s e.g. conditional, arithmetic, application [-Wcpp] 303 | #warning TODO: fixme evaluation of various repl_expression-s e.g. conditional, arithmetic, application | ^~~ cmdrepl_rps.cc:344:2: warning: #warning unimplemented rps_full_evaluate_repl_composite_object [-Wcpp] 344 | #warning unimplemented rps_full_evaluate_repl_composite_object | ^~~ cmdrepl_rps.cc:771:2: warning: #warning unimplemented Rps_CallFrame::interpret_repl_statement [-Wcpp] 771 | #warning unimplemented Rps_CallFrame::interpret_repl_statement | ^~~ cmdrepl_rps.cc:930:2: warning: #warning rpsapply_61pgHb5KRq600RLnKD should use wordexp(3) on the string [-Wcpp] 930 | #warning rpsapply_61pgHb5KRq600RLnKD should use wordexp(3) on the string | ^~~ cmdrepl_rps.cc:939:2: warning: #warning incomplete rpsapply_61pgHb5KRq600RLnKD for REPL command dump [-Wcpp] 939 | #warning incomplete rpsapply_61pgHb5KRq600RLnKD for REPL command dump | ^~~ cmdrepl_rps.cc:1050:2: warning: #warning we probably want to display some common payloads here [-Wcpp] 1050 | #warning we probably want to display some common payloads here | ^~~ cmdrepl_rps.cc:1115:2: warning: #warning REPL command show may need some local Rps_TokenSource [-Wcpp] 1115 | #warning REPL command show may need some local Rps_TokenSource | ^~~ cmdrepl_rps.cc:1206:2: warning: #warning this code should be moved into rps_show_object_for_repl above [-Wcpp] 1206 | #warning this code should be moved into rps_show_object_for_repl above | ^~~ cmdrepl_rps.cc:1212:2: warning: #warning incomplete rpsapply_7WsQyJK6lty02uz5KT should define and call rps_show_instance_for_repl [-Wcpp] 1212 | #warning incomplete rpsapply_7WsQyJK6lty02uz5KT should define and call rps_show_instance_for_repl | ^~~ cmdrepl_rps.cc:1220:2: warning: #warning incomplete rpsapply_7WsQyJK6lty02uz5KT for REPL command show [-Wcpp] 1220 | #warning incomplete rpsapply_7WsQyJK6lty02uz5KT for REPL command show | ^~~ cmdrepl_rps.cc:1262:2: warning: #warning incomplete rpsapply_2TZNwgyOdVd001uasl for REPL command help [-Wcpp] 1262 | #warning incomplete rpsapply_2TZNwgyOdVd001uasl for REPL command help | ^~~ cmdrepl_rps.cc:1298:2: warning: #warning incomplete rpsapply_28DGtmXCyOX02AuPLd for REPL command put [-Wcpp] 1298 | #warni
[Bug plugins/66991] GCCPLUGIN_VERSION_MAJOR == 5 & GCCPLUGIN_VERSION_MINOR == 5 for GCC 5.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66991 --- Comment #5 from Basile Starynkevitch --- Now Debian bug#793478; sorry for the noise here...
[Bug plugins/66991] GCCPLUGIN_VERSION_MAJOR == 5 & GCCPLUGIN_VERSION_MINOR == 5 for GCC 5.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66991 --- Comment #4 from Basile Starynkevitch --- Known to Debian thru https://lists.debian.org/debian-gcc/2015/07/msg00167.html
[Bug plugins/66991] GCCPLUGIN_VERSION_MAJOR == 5 & GCCPLUGIN_VERSION_MINOR == 5 for GCC 5.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66991 --- Comment #3 from Basile Starynkevitch --- It is Debian specific, very probably. I reported a Debian bug (but did not get any ack yet)
[Bug plugins/66991] GCCPLUGIN_VERSION_MAJOR == 5 & GCCPLUGIN_VERSION_MINOR == 5 for GCC 5.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66991 --- Comment #2 from Basile Starynkevitch --- It looks like this bug is corrected in GCC 5.2 (I'm compiling the FSF tree).
[Bug plugins/66991] New: GCCPLUGIN_VERSION_MAJOR == 5 & GCCPLUGIN_VERSION_MINOR == 5 for GCC 5.5.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66991 Bug ID: 66991 Summary: GCCPLUGIN_VERSION_MAJOR == 5 & GCCPLUGIN_VERSION_MINOR == 5 for GCC 5.5.1 Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: basile at starynkevitch dot net Target Milestone: --- At least on my GNU/Linux/Debian/x86-64/Unstable the /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/plugin-version.h file from package gcc-5-plugin-dev version 5.1.1-14 contains incorrectly the following lines: #define GCCPLUGIN_VERSION_MAJOR 5 #define GCCPLUGIN_VERSION_MINOR 5 #define GCCPLUGIN_VERSION_PATCHLEVEL 5 #define GCCPLUGIN_VERSION (GCCPLUGIN_VERSION_MAJOR*1000 + GCCPLUGIN_VERSION_MINOR) The GCCPLUGIN_VERSION_MINOR & GCCPLUGIN_VERSION_PATCHLEVEL are both incorrect. They should be 1 & 1 respectively. (It could be a Debian specific bug, but I don't think so. This file is generated at GCC build time).
[Bug c++/51092] ICE array std::pair initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51092 basile at starynkevitch dot net changed: What|Removed |Added Summary|ICE std::pair |ICE array std::pair |initialization |initialization --- Comment #1 from basile at starynkevitch dot net 2011-11-11 11:32:34 UTC --- See http://stackoverflow.com/questions/8091422/map-initialization-object-code-is-50-times-larger-than-source-code/8091484#8091484
[Bug c++/51092] New: ICE std::pair initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51092 Bug #: 51092 Summary: ICE std::pair initialization Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: bas...@starynkevitch.net Created attachment 25794 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25794 init of array of std::pair On Debian/Sid/AMD64 with GCC Debian 4.6.2-4 the attached file got a SEGV. % g++ -O -std=gnu++0x -S -fverbose-asm basile.cc basile.cc:8:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/ccOtez1K.out file, please attach this to your bugreport.
[Bug bootstrap/39810] [melt] - revision 146327 - compiler-probe.c:106: undefined reference to `unlikely'
--- Comment #3 from basile at starynkevitch dot net 2009-04-27 13:16 --- and the undefined reference to `ppl_io_asprint_Coefficient' messages is because you need a more recent PPL library, at least 0.10.2 or 0.11, or the latest PPL git snapshot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39810
[Bug bootstrap/39810] [melt] - revision 146327 - compiler-probe.c:106: undefined reference to `unlikely'
--- Comment #2 from basile at starynkevitch dot net 2009-04-27 13:14 --- I believe this has been corrected in recent MELT branch, ie svn rev146839 and perhaps before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39810
[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
--- Comment #7 from basile at starynkevitch dot net 2009-03-23 18:16 --- fopencookie is removed in rev145010 of MELT branch. I'm using a temporary kludge , calling an unstable function inside PPL. So You'll need a recent PPL snapshot (obtained thru GIT). http://www.cs.unipr.it/pipermail/ppl-devel/2009-March/014162.html Better fix will be available after PPL gets a better function to debugprint inside a string buffer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
--- Comment #6 from basile at starynkevitch dot net 2009-03-22 12:38 --- Subject: Re: [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable rob1weld at aol dot com wrote: > --- Comment #4 from rob1weld at aol dot com 2009-03-22 09:57 --- > I am aware that the "_r" issues have been addressed and will test the > 'soon to arrive' fopencookie() code next week on i386-pc-solaris2.11 > to ensure that non-Linux Platforms have a chance to vompile 'melt'. > > Rob > > > I will be able to remove the fopencookie by using a feature which has been commit to PPL ((git snapshot) only a few hours ago. So you'll need to download and rebuild the PPL library (either from its git repository, or forthecoming 0.10.1 or 0.11 version. I'll probably work on that issue tomorrow monday. Regards. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
--- Comment #5 from basile at starynkevitch dot net 2009-03-22 12:34 --- With using the very latest PPL snapshot (from GIT), or PPL 0.10.1 or 0.11 I would be able to remove the fopencookie in a couple of days. But of course, you'll need to download a very new PPL and build it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug bootstrap/39484] [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c -> SIGSEGV
--- Comment #3 from basile at starynkevitch dot net 2009-03-17 19:07 --- I applied a slightly simplified variant of melt-patch-2.patch above as rev144917 Thanks Rob. It probably works! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
[Bug bootstrap/39484] [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c -> SIGSEGV
--- Comment #1 from basile at starynkevitch dot net 2009-03-17 16:39 --- Bug confirmed. The bug seems to appear on x86 (not amd64) when configure-ing with --prefix=/usr/ A very temporary workaround could be to configure with --prefix=/usr/local/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
[Bug bootstrap/39483] [melt] - revision 144904 - Configuring with "--with-gc=zone" fails in ggc-zone.c
--- Comment #2 from basile at starynkevitch dot net 2009-03-17 15:57 --- Thanks. Patch commited as rev 144905 of MELT branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39483
[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
--- Comment #3 from basile at starynkevitch dot net 2009-03-17 08:18 --- I replaced lrand48_r by lrand48... Regarding fopencookie, it could be fixed 1. by using next PPL (0.11) version or 2. by linking some specific PPL file (ppl/interfaces/C/tests/print_to_buffer.cc) Regards -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug c++/22521] internal compiler error: in tsubst_copy
--- Additional Comments From basile at starynkevitch dot net 2005-07-17 14:31 --- Created an attachment (id=9293) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9293&action=view) preprocessor output (gnuzipped) of failing code Sample code (preprocessor output with g++ -C -E and appropriate -I) which demonstrate thje bug. Sorry, I've got no smaller case. But I guess the problem lies within the Jaksy_TVector template, which is not that big. Most of the includes come from Qt4 (not very used) and my Qish garbage collector (see http://starynkevitch.net/Basile/qishintro.html for more, get its latest snapshot). The attachement is self-contained and does not need any other file. I tried several other ways of coding, and the same bug appears. Regards. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22521
[Bug c++/22521] New: internal compiler error: in tsubst_copy
the preprocessed file, which I uploaded on
http://starynkevitch.net/Basile/jaksy-g++-4.1.0-20050717-bug.ii.gz (md5sum of
gzipped file is e71436c0b8f93cef110aa6068b13bcb3) produce a reproducible
compiler bug:
/usr/local/bin/g++_4_snap -c jaksy.ii
jaksy.hh: In constructor 'Jaksy_TVector::add_first(VectorT*, ScalarT)::QishCpp_Locals::QishCpp_Locals() [with
int ctag = 1007, ScalarT = void*, VectorT = Jaksy_Vector]':
jaksy.hh:672: instantiated from 'static Jaksy_TVector*
Jaksy_TVector::add_first(VectorT*, ScalarT) [with int
ctag = 1007, ScalarT = void*, VectorT = Jaksy_Vector]'
jaksy.hh:734: instantiated from here
jaksy.hh:672: internal compiler error: in tsubst_copy, at cp/pt.c:7684
Please submit a full bug report,
This bug is the same with g++-4.0 from debian/sid and with latest CVS (from
yesterday) of gcc.
(this is from a free GPL/LPGL software I am currently developping. The program
may be not very meaningful yet; it is experimental).
--
Summary: internal compiler error: in tsubst_copy
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: basile at starynkevitch dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22521
