[Bug c++/107191] [modules] ICE when importing module partition (internal compiler error: in tree_node, at cp/module.cc:9061)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107191 --- Comment #2 from Bruce Adams --- Also tried with gcc 12.1 >g++-12 --version g++-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0 ``` /usr/bin/g++-12 -fmodules-ts -std=gnu++20 -MD -MT CMakeFiles/gccice.dir/Foo.cpp.o -MF CMakeFiles/gccice.dir/Foo.cpp.o.d -o CMakeFiles/gccice.dir/Foo.cpp.o -c /home/brucea/projects/jobs/gccice/Foo.cpp /home/brucea/projects/jobs/gccice/Foo.cpp:2:8: internal compiler error: in tree_node, at cp/module.cc:9078 2 | export module Foo; |^~ 0x65fabd trees_out::tree_node(tree_node*) ../../src/gcc/cp/module.cc:9078 0x78a72b trees_out::core_vals(tree_node*) ../../src/gcc/cp/module.cc:5922 0x78e3bf trees_out::tree_node_vals(tree_node*) ../../src/gcc/cp/module.cc:7072 0x78e3bf trees_out::tree_value(tree_node*) ../../src/gcc/cp/module.cc:8909 0x787354 trees_out::tree_node(tree_node*) ../../src/gcc/cp/module.cc:9107 0x78a72b trees_out::core_vals(tree_node*) ```
[Bug c++/107192] [modules] internal compiler error: Segmentation fault parsing line "module :Bar;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107192 --- Comment #1 from Bruce Adams --- Still occurs if I use gcc 12.1 >g++-12 --version g++-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0 ``` [ 50%] Building CXX object CMakeFiles/gccice.dir/Bar.cpp.o /usr/bin/g++-12 -fmodules-ts -std=gnu++20 -MD -MT CMakeFiles/gccice.dir/Bar.cpp.o -MF CMakeFiles/gccice.dir/Bar.cpp.o.d -o CMakeFiles/gccice.dir/Bar.cpp.o -c /home/brucea/projects/jobs/gccice2/Bar.cpp /home/brucea/projects/jobs/gccice2/Bar.cpp:8:9: internal compiler error: Segmentation fault 8 | module :Bar; | ^~~ 0xd910e3 crash_signal ../../src/gcc/toplev.cc:322 0x7f5f531b851f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x783313 module_state::is_partition() const ../../src/gcc/cp/module.cc:3482 0x783313 get_module(tree_node*, module_state*, bool) ../../src/gcc/cp/module.cc:13782 0x7b3a91 cp_parser_module_name ../../src/gcc/cp/parser.cc:14522 0x7da1e2 cp_parser_module_declaration ../../src/gcc/cp/parser.cc:14595 0x7fa3d3 cp_parser_translation_unit ../../src/gcc/cp/parser.cc:4968 0x7fa3d3 c_parse_file() ../../src/gcc/cp/parser.cc:48068 0x8e6335 c_common_parse_file() ../../src/gcc/c-family/c-opts.cc:1240 ```
[Bug c++/107191] [modules] ICE when importing module partition (internal compiler error: in tree_node, at cp/module.cc:9061)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107191 --- Comment #1 from Bruce Adams --- I also produced a different segfault while trying to reproduce this - see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107192
[Bug c++/107192] New: [modules] internal compiler error: Segmentation fault parsing line "module :Bar;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107192 Bug ID: 107192 Summary: [modules] internal compiler error: Segmentation fault parsing line "module :Bar;" Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tortoise_74 at yahoo dot co.uk Target Milestone: --- Created attachment 53682 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53682&action=edit Sample code to reproduce segfault Found while trying to create a reproducer for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107191 When attempting to compile the following code: ``` module; module :Bar; ``` I got: ``` [ 25%] Building CXX object CMakeFiles/gccice.dir/Bar.cpp.o /usr/bin/c++ -fmodules-ts -std=gnu++20 -MD -MT CMakeFiles/gccice.dir/Bar.cpp.o -MF CMakeFiles/gccice.dir/Bar.cpp.o.d -o CMakeFiles/gccice.dir/Bar.cpp.o -c /home/brucea/projects/jobs/gccice2/Bar.cpp /home/brucea/projects/jobs/gccice2/Bar.cpp:8:9: internal compiler error: Segmentation fault 8 | module :Bar; | ^~~ 0x7f02a38e151f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x7f02a38c8d8f __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7f02a38c8e3f __libc_start_main_impl ../csu/libc-start.c:392 Please submit a full bug report, with preprocessed source if appropriate. ``` This may or may not be legal code but a segfault is incorrect. >gcc --version gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
[Bug c++/99769] [modules] internal compiler error: in tree_node, at cp/module.cc:9105 when compile module partitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99769 --- Comment #4 from Bruce Adams --- I had a issue I believed to be related but in attempting to create a reproducer got several different ICEs so I have submitted a separate ticket - see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107191
[Bug c++/107191] New: [modules] ICE when importing module partition (internal compiler error: in tree_node, at cp/module.cc:9061)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107191 Bug ID: 107191 Summary: [modules] ICE when importing module partition (internal compiler error: in tree_node, at cp/module.cc:9061) Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tortoise_74 at yahoo dot co.uk Target Milestone: --- Created attachment 53681 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53681&action=edit Sample code to reproduce the above I have been trying to create a module composed of 2 partitions one of which imports the other. This gives me the error as below: ``` [ 25%] Building CXX object CMakeFiles/gccice.dir/Foo.cpp.o /usr/bin/c++ -fmodules-ts -std=gnu++20 -MD -MT CMakeFiles/gccice.dir/Foo.cpp.o -MF CMakeFiles/gccice.dir/Foo.cpp.o.d -o CMakeFiles/gccice.dir/Foo.cpp.o -c /home/brucea/projects/jobs/gccice/Foo.cpp /home/brucea/projects/jobs/gccice/Foo.cpp:2:8: internal compiler error: in tree_node, at cp/module.cc:9061 2 | export module Foo; |^~ 0x7fe43f807d8f __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7fe43f807e3f __libc_start_main_impl ../csu/libc-start.c:392 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. make[2]: *** [CMakeFiles/gccice.dir/build.make:76: CMakeFiles/gccice.dir/Foo.cpp.o] Error 1 make[2]: Leaving directory '/home/brucea/projects/jobs/gccice/target' make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/gccice.dir/all] Error 2 make[1]: Leaving directory '/home/brucea/projects/jobs/gccice/target' ``` I thought this might be the same as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99769 The line number is different but I am using the ubuntu version of gcc which might have small differences: > gcc --version gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0 In trying to create a reproducer I have encountered different errors: ``` /tmp/codetest/Foo.cpp:2:8: internal compiler error: in tree_node, at cp/module.cc:9061 2 | export module Foo; |^~ 0xe3223b internal_error(char const*, ...) ???:0 0xe28d63 fancy_abort(char const*, int, char const*) ???:0 0x9dd5e6 trees_out::tree_node(tree_node*) ???:0 0x9ddbdf trees_out::core_vals(tree_node*) ???:0 0x9de4ba trees_out::tree_node_vals(tree_node*) ???:0 0x9df707 trees_out::tree_value(tree_node*) ???:0 0x9dd60d trees_out::tree_node(tree_node*) ???:0 0x9ddbdf trees_out::core_vals(tree_node*) ???:0 0x9de4ba trees_out::tree_node_vals(tree_node*) ???:0 0x9df707 trees_out::tree_value(tree_node*) ???:0 0x9dd60d trees_out::tree_node(tree_node*) ???:0 0x9ddbdf trees_out::core_vals(tree_node*) ???:0 0x9de4ba trees_out::tree_node_vals(tree_node*) ???:0 0x9df707 trees_out::tree_value(tree_node*) ???:0 0x9dd60d trees_out::tree_node(tree_node*) ???:0 0x9ddbdf trees_out::core_vals(tree_node*) ???:0 0x9de4ba trees_out::tree_node_vals(tree_node*) ???:0 0x9df707 trees_out::tree_value(tree_node*) ???:0 0x9dd60d trees_out::tree_node(tree_node*) ???:0 0x9ddbdf trees_out::core_vals(tree_node*) ???:0 Please submit a full bug report, ``` And by just adding #include : ``` 50%] Building CXX object CMakeFiles/gccice.dir/Snafu.cpp.o /usr/bin/c++ -fmodules-ts -std=gnu++20 -MD -MT CMakeFiles/gccice.dir/Snafu.cpp.o -MF CMakeFiles/gccice.dir/Snafu.cpp.o.d -o CMakeFiles/gccice.dir/Snafu.cpp.o -c /tmp/codetest/Snafu.cpp In file included from /usr/include/c++/11/bits/locale_classes.h:857, from /usr/include/c++/11/bits/ios_base.h:41, from /usr/include/c++/11/ios:42, from /usr/include/c++/11/istream:38, from /usr/include/c++/11/sstream:38, from /tmp/codetest/Bar.cpp:7, of module Foo:Bar, imported at /tmp/codetest/Snafu.cpp:9: /usr/include/c++/11/bits/locale_classes.tcc: In instantiation of 'const _Facet& std::use_facet(const std::locale&) [with _Facet = std::__cxx11::numpunct]': /usr/include/c++/11/bits/locale_facets.tcc:80:66: required from 'void std::__numpunct_cache@Foo:Bar<_CharT>::_M_cache(const std::locale&) [with _CharT = char]' /usr/include/c++/11/bits/locale_facets.tcc:63:18: required from 'const std::__numpunct_cache@Foo:Bar<_CharT>* std::__use_cache@Foo:Bar >::operator()(const std::locale&) const [with _CharT = char]' /usr/include/c++/11/bits/locale_facets.tcc:384:33: required from '_InIter std::num_get<_CharT, _InIter>::_M_extract_int(_InIter, _InIter, std::ios_base&, std::ios_base::iostate&, _ValueT&) const [wi
[Bug target/61956] problem linking cilk on RHEL4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61956 --- Comment #2 from Bruce Adams --- I have tried using a newer binutils (2.24) either installed before attempting to build gcc or in a combined tree build. The combined tree build complains that binutils/bfd is already configured when I run make bootstrap. mkdir -p -- ./bfd Configuring in ./bfd configure: creating cache ./config.cache [snip] checking for style of include used by make... GNU configure: error: source directory already configured; run "make distclean" there first make[4]: *** [configure-bfd] Error 1 make[4]: Leaving directory `/development/brucea/gcc/build/binutils' make[3]: *** [all] Error 2 make[3]: Leaving directory `/development/brucea/gcc/build/binutils' make[2]: *** [all-stage1-binutils] Error 2 make[2]: Leaving directory `/development/brucea/gcc/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/development/brucea/gcc/build' make: *** [bootstrap] Error 2 However, running configure using --disable-libcilkrts (in addition to the already required --disable-libsanitiser ) which is not documented results in a useable gcc 4.9.1 (with c++ working but presumably cilk++ broken).
[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955 --- Comment #3 from Bruce Adams --- Running configure using --disable-libcilkrts (in addition to --disable-libsanitiser) which is not documented results in a useable gcc 4.9.1 (with c++ working but presumably cilk++ broken).
[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955 --- Comment #2 from Bruce Adams --- Running configure using --disable-libcilkrts (in addition to --disable-libsanitiser) which is not documented results in a useable gcc 4.9.1 (with c++ working but presumably cilk++ broken).
[Bug c++/61956] New: problem links cilk on RHEL4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61956 Bug ID: 61956 Summary: problem links cilk on RHEL4 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tortoise_74 at yahoo dot co.uk Following on from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955 I tried compiling gcc4.9 on RHEL4 using configure --disable-libsanitizer. It progresses the build which subsequently fails when linking cilk. Building worked with the previous version gcc 4.8.1 brucea@:development/brucea/gcc>lsb_release -a LSB Version: :core-3.0-amd64:core-3.0-ia32:core-3.0-noarch:graphics-3.0-amd64:graphics-3.0-ia32:graphics-3.0-noarch Distributor ID:RedHatEnterpriseES Description:Red Hat Enterprise Linux ES release 4 (Nahant Update 5) Release:4 Codename:NahantUpdate5 brucea@:development/brucea/gcc>uname -a Linux uktnswg-tvdev01.tnsad.com 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux Build using configure/make/install for each of the following in turn gmp-5.0.2.tar.bz2 mpfr-3.1.0.tar.bz2 mpc-0.9.tar.gz gcc-4.9.0.tar.bz2 or gcc-4.9.1.tar.bz2 Output: libtool: link: /development/brucea/gcc/build/./gcc/xg++ -B/development/brucea/gcc/build/./gcc/ -nostdinc++ -nostdinc++ -I/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/development/brucea/gcc/gcc-4.9.1/libstdc++-v3/libsupc++ -I/development/brucea/gcc/gcc-4.9.1/libstdc++-v3/include/backward -I/development/brucea/gcc/gcc-4.9.1/libstdc++-v3/testsuite/util -L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/bin/ -B/home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/lib/ -isystem /home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/include -isystem /home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/sys-include-shared -nostdlib /usr/lib/../lib64/crti.o /development/brucea/gcc/build/./gcc/crtbeginS.o .libs/cilk-abi-vla.o .libs/os-unix-sysdep.o .libs/bug.o .libs/cilk-abi.o .libs/cilk-abi-cilk-for.o .libs/cilk-abi-vla-internal.o .libs/cilk_api.o .libs/cilk_fiber.o .libs/cilk_fiber-unix.o .libs/cilk_malloc.o .libs/c_reducers.o .libs/except-gcc.o .libs/frame_malloc.o .libs/full_frame.o .libs/global_state.o .libs/jmpbuf.o .libs/local_state.o .libs/metacall_impl.o .libs/os_mutex-unix.o .libs/os-unix.o .libs/pedigrees.o .libs/record-replay.o .libs/reducer_impl.o .libs/scheduler.o .libs/signal_node.o .libs/spin_mutex.o .libs/stats.o .libs/symbol_test.o .libs/sysdep-unix.o .libs/worker_mutex.o -Wl,-rpath -Wl,/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -Wl,-rpath -Wl,/home/brucea/gcc4.9.1/lib/../lib64 -L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -lpthread -ldl -L/development/brucea/gcc/build/./gcc -L/lib/../lib64 -L/usr/lib/../lib64 /development/brucea/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so -lm -lc -lgcc_s /development/brucea/gcc/build/./gcc/crtendS.o /usr/lib/../lib64/crtn.o -Wl,--version-script -Wl,../../../gcc-4.9.1/libcilkrts/runtime/linux-symbols.ver -Wl,-soname -Wl,libcilkrts.so.5 -o .libs/libcilkrts.so.5.0.0 /usr/bin/ld: .libs/cilk-abi.o: relocation R_X86_64_PC32 against `__cilkrts_get_tls_worker' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status make[2]: *** [libcilkrts.la] Error 1 make[2]: Leaving directory `/development/brucea/gcc/build/x86_64-unknown-linux-gnu/libcilkrts' make[1]: *** [install-target-libcilkrts] Error 2 make[1]: Leaving directory `/development/brucea/gcc/build' make: *** [install] Error 2 Command exited with non-zero status 2
[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955 --- Comment #1 from Bruce Adams --- configuring with --disable-libsantizer progresses the build but it fails later on linking cilk. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61956
[Bug sanitizer/61955] New: libsanitizer fails to compile on RHEL4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955 Bug ID: 61955 Summary: libsanitizer fails to compile on RHEL4 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: tortoise_74 at yahoo dot co.uk CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org gcc 4.9.0 fails to compile on a standard Red Hat 4 system due to problems compiling libsantiser. See also https://gcc.gnu.org/ml/gcc/2014-05/msg00219.html The work around of configuring gcc --disable-libsanitizer progresses the build (which then fails for other reasons see below) I would have thought this was a reasonably popular target still but there do not seem to be any other reports. I tried again using gcc 4.9.1 and the problem still occurs. This target build successfully using the same method for gcc 4.8.1 brucea@:development/brucea/gcc>lsb_release -a LSB Version: :core-3.0-amd64:core-3.0-ia32:core-3.0-noarch:graphics-3.0-amd64:graphics-3.0-ia32:graphics-3.0-noarch Distributor ID:RedHatEnterpriseES Description:Red Hat Enterprise Linux ES release 4 (Nahant Update 5) Release:4 Codename:NahantUpdate5 brucea@:development/brucea/gcc>uname -a Linux uktnswg-tvdev01.tnsad.com 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux Build using configure/make/install for each of the following in turn gmp-5.0.2.tar.bz2 mpfr-3.1.0.tar.bz2 mpc-0.9.tar.gz gcc-4.9.0.tar.bz2 or gcc-4.9.1.tar.bz2 libtool: compile: /development/brucea/gcc/build/build/./gcc/xgcc -shared-libgcc -B/development/brucea/gcc/build/build/./gcc - nostdinc++ -L/development/brucea/gcc/build/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/development/brucea/gcc/build/bui ld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/development/brucea/gcc/build/build/x86_64-unknown-linux-gnu/libstdc++-v3 /libsupc++/.libs -B/home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/bin/ -B/home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/lib/ - isystem /home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/include -isystem /home/brucea/gcc4.9.1/x86_64-unknown-linux-gnu/sys-inc lude -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc-4.9.1/ libsanitizer/sanitizer_common -I.. -I ../../../../gcc-4.9.1/libsanitizer/include -isystem ../../../../gcc-4.9.1/libsanitizer/i nclude/system -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno- rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstd c++-v3/include/x86_64-unknown-linux-gnu -I../../../../gcc-4.9.1/libsanitizer/../libstdc++-v3/libsupc++ -DSANITIZER_LIBBACKTRAC E -DSANITIZER_CP_DEMANGLE -I ../../../../gcc-4.9.1/libsanitizer/../libbacktrace -I ../libbacktrace -I ../../../../gcc-4.9.1/li bsanitizer/../include -include ../../../../gcc-4.9.1/libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -D_GNU_SOURCE -MT san itizer_platform_limits_linux.lo -MD -MP -MF .deps/sanitizer_platform_limits_linux.Tpo -c ../../../../gcc-4.9.1/libsanitizer/sa nitizer_common/sanitizer_platform_limits_linux.cc -fPIC -DPIC -o .libs/sanitizer_platform_limits_linux.o In file included from ../../../../gcc-4.9.1/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:49:0: ../../../../gcc-4.9.1/libsanitizer/include/system/linux/aio_abi.h:2:32: fatal error: linux/aio_abi.h: No such file or director y #include_next ^ compilation terminated. make[3]: *** [sanitizer_platform_limits_linux.lo] Error 1 make[3]: Leaving directory `/development/brucea/gcc/build/build/x86_64-unknown-linux-gnu/libsanitizer/sanitizer_common' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/development/brucea/gcc/build/build/x86_64-unknown-linux-gnu/libsanitizer' make[1]: *** [install-target-libsanitizer] Error 2 make[1]: Leaving directory `/development/brucea/gcc/build/build' make: *** [install] Error 2
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #129 from Bruce Adams 2011-11-29 10:49:08 UTC --- doh! You are entirely right. It works just fine on the 2019 snapshot. Sorry for wasting time there. I was too fast on the email trigger. Mea culpa.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #127 from Bruce Adams 2011-11-26 12:10:26 UTC --- (In reply to comment #126) > "201103" of course. Perhaps it is my misunderstanding. I assume __cpluscplus is defined by the compiler. Could it come from a system header or system library instead? g++ must include the std C++ library because otherwise I wouldn't be able to use unique_ptr with g++ 4.7 when I can't use it with g++ 4.1. Could someone confirm whether this change is in the 2019 snapshot or only in main please?
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
Bruce Adams changed:
What|Removed |Added
CC||tortoise_74 at yahoo dot
||co.uk
--- Comment #124 from Bruce Adams 2011-11-25
18:33:25 UTC ---
My understanding of the last comment is that for -std=c++11 _cplusplus should
be set so that "#if __cplusplus > 201100L" can be used to conditionally compile
as C++03 vs C++11.
I would expect this to be in the snapshot I'm using but it doesn't seem to be.
Has it regressed or do we need to wait for the next snapshot release?
What other way is there to distinguish C++03 and C++11 in source as a
workaround?
#include
int main(int argc, char* argv[])
{
std::cout << __cplusplus << std::endl;
return 0;
}
#!/bin/sh
gcc --version
gcc -Wconversion blah.cpp -oblah -lstdc++
./blah
export LD_LIBRARY_PATH=/opt/gcc4.7/lib:$LD_LIBRARY_PATH
export PATH=/opt/gcc4.7/bin:$PATH
/opt/gcc4.7/bin/gcc --version
/opt/gcc4.7/bin/gcc -std=c++03 blah.cpp -oblah2 -lstdc++
./blah
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
[snip]
1
gcc (GCC) 4.7.0 2019 (experimental)
[snip]
1
[Bug c/51294] spurious warning from -Wconversion in C and C++ in conditional expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294 --- Comment #4 from Bruce Adams 2011-11-24 17:09:56 UTC --- Shouldn't integral conversion rules apply if the types of the second and third arguments to a conditional expression differ. So zero should be converted from the default int to a char as presumably the older version of gcc did. Perhaps a language lawyer could explain why this is or isn't a bug. Though obviously warnings are not covered by the standard. Note: (haveBar?bar_:(char)0) is not an acceptable workaround for C++ if -Wold-style-cast is used (which is in my experience typical). It would have to be (haveBar?bar_:static_cast(0)) which is a notch higher in annoyingness.
[Bug c/51294] spurious warning from -Wconversion in C and C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294 --- Comment #1 from Bruce Adams 2011-11-24 11:35:24 UTC --- Probably unncessary but the OS is RHEL5 on a 32bit machine. brucea@:home/brucea/spurious>lsb_release -a LSB Version: :core-4.0-ia32:core-4.0-noarch:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-ia32:printing-4.0-noarch Distributor ID: RedHatEnterpriseClient Description:Red Hat Enterprise Linux Client release 5.7 (Tikanga) Release:5.7 Codename: Tikanga
[Bug c/51294] New: spurious warning from -Wconversion in C and C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294
Bug #: 51294
Summary: spurious warning from -Wconversion in C and C++
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tortoise...@yahoo.co.uk
The code below produces a spurious warning when compiled with -Wconversion.
0 is a const so the compiler should be able to choose the correct type. This
works with gcc 4.1 on redhat 5 but not the latest snapshot of gcc 4.7 (which I
am trialing for its c++11 support).
I do not have any intermediate compiler versions to test with.
spurious.cpp:
class foo
{
char bar;
foo(bool haveBar, char bar_):
bar(haveBar?bar_:0)
{
}
};
##
test.sh
#!/bin/sh
gcc --version
gcc -Wconversion -c spurious.cpp
export LD_LIBRARY_PATH=/opt/gcc4.7/lib:$LD_LIBRARY_PATH
export PATH=/opt/gcc4.7/bin:$PATH
/opt/gcc4.7/bin/gcc --version
/opt/gcc4.7/bin/gcc -Werror -Wconversion -c spurious.cpp
##
brucea@:home/brucea/spurious>./test.sh
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
Copyright (C) 2006 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.
gcc (GCC) 4.7.0 2019 (experimental)
Copyright (C) 2011 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.
spurious.cpp: In constructor ‘foo::foo(bool, char)’:
spurious.cpp:8:25: error: conversion to ‘char’ from ‘int’ may alter its value
[-Werror=conversion]
cc1plus: all warnings being treated as errors
##
The workaround is either to disable the warning with -Wno-conversion or add
unecessary constants as below. I don't think this is acceptable.
class foo2
{
static const char zero = 0;
char bar;
foo2(bool haveBar, char bar_):
bar(haveBar?bar_:zero)
{
}
};
This is also a bug in the C front-end:
void foo(int haveBar, char bar_)
{
char zuul = haveBar?bar_:0;
}
