[Bug c++/95878] New: ICE when compiling code that mixes an empty class, [[no_unique_address]] and non-trivial default and copy constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95878
Bug ID: 95878
Summary: ICE when compiling code that mixes an empty class,
[[no_unique_address]] and non-trivial default and copy
constructors
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris.staletic at gmail dot com
Target Milestone: ---
Hello,
first, apologies for a bad title. I was unsure how to make it more descriptive.
My repro case looks suspiciously like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432
However, the bug in 90432 has been fixed in 10.1 and 9.3. I've encountered a
similar code that still triggers an ICE. Just like 90432, gcc 8 works fine.
I've encountered a non-minimal version of this bug while working on the
nanorange library.
The minimal code that causes ICE:
struct istream_iterator {
istream_iterator() {}
istream_iterator(const istream_iterator&) {}
};
istream_iterator next(istream_iterator&& bound) {
return static_cast(bound);
}
struct copy_result {
[[no_unique_address]] istream_iterator in;
};
int main() {
copy_result result{next(istream_iterator{})};
}
during RTL pass: expand
: In function 'int main()':
:15:45: internal compiler error: in assign_temp, at function.c:982
15 | copy_result result{next(istream_iterator{})};
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
[Bug c++/93711] [9/10/11 Regression] ICE: [[no_unique_address] when constructing via template helper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711 --- Comment #7 from Boris Staletic --- I don't know if this is the same problem, since the actual `std::istream_iterator` isn't empty, unlike in the other test cases. If the following is a different problem, sorry up front for the noise. https://godbolt.org/z/XAM9o7 This is the actual thing I've come across during a pull request for NanoRange library. DIfferences from the above test cases: - ICE is there even at `-Og`, as well as `-O0` - The bottom example shows that wrapping the call to `fn()` in `std::move()` avoids the ICE. If this is a separate issue and thus noise, I'll open a separate issue.
[Bug libstdc++/91067] New: Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 Bug ID: 91067 Summary: Clang compiler can't link executable if std::filesystem::directory_iterator is encountered Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: boris.staletic at gmail dot com Target Milestone: --- When compiling with clang, a code that contains an object of the type std::filesystem::directory_iterator produces the following linker error: /usr/sbin/ld: /tmp/bar-5627f7.o: in function `std::filesystem::__cxx11::directory_iterator::directory_iterator()': bar.cpp:(.text._ZNSt10filesystem7__cxx1118directory_iteratorC2Ev[_ZNSt10filesystem7__cxx1118directory_iteratorC2Ev]+0x1): undefined reference to `std::__shared_ptr::__shared_ptr()' clang-8: error: linker command failed with exit code 1 (use -v to see invocation) The minimal reproducer had to be preprocessed with clang to avoid errors like "/usr/include/c++/9.1.0/bits/stl_function.h:475:6: error: use of undeclared identifier '__builtin_is_constant_evaluated'" when compiling. For this reason I will attach a non-preprocessed file too. Clang version - 8.0.0 (tags/RELEASE_800/final) Clang command line - clang++ -std=c++17 bar.ii -O1 -lstdc++fs GCC version - 9.1.0 Target - x86_64-pc-linux-gnu GCC compile time configuration options: COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto Thread model: posix Additional note: Changing the optimization level can avoid the linker error.
[Bug libstdc++/91067] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #2 from Boris Staletic --- Created attachment 46549 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46549&action=edit Non-preprocessed file
[Bug libstdc++/91067] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #1 from Boris Staletic --- Created attachment 46548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46548&action=edit Minimal reproducer - preprocessed with clang
[Bug c++/86422] New: G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 Bug ID: 86422 Summary: G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: boris.staletic at gmail dot com Target Milestone: --- My gcc version is 8.1.0. I have not tried with the latest gcc snapshot. If requested, I will compile a gcc snapshot and try to reproduce. My CHOST triple is x86_64-pc-linux-gnu, but I've also managed to get g++ to ICE with an arm-linux-gnueabihf-g++, version 7.3.0, CHOST arm-linux-gnueabihf. My gcc has been configured with: /var/tmp/portage/sys-devel/gcc-8.1.0-r3/work/gcc-8.1.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.1.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.1.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.1.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.1.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/include/g++-v8 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.1.0/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 8.1.0-r3 p1.3' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap --enable-vtable-verify --enable-libvtv --disable-libquadmath --enable-lto --without-isl --enable-libsanitizer --enable-default-pie --enable-default-ssp The preprocessed file, while being "just" a static array within a trivial function, it's almost 6MB, so instead of attaching the file I have to post the link: https://raw.githubusercontent.com/bstaletic/gcc_ice/master/gcc/CodePoint.ii When compiled with "g++ -S CodePoint.ii -o CodePoint.s", produces an empty "CodePoint.s" and the following error: g++: internal compiler error: Segmentation fault signal terminated program cc1plus Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.gentoo.org/> for instructions. - Simple changes that avoid ICE: - Adding "-flto". - Changing the "std::string"s in the "RawCodePoint" (lines 19480 to 19483) struct to a "char*". - Makes the compile time really short, produces the assembly. - Changing the "std::string"s in the "RawCodePoint" struct to a "char[]". - Somewhat shorter compile time, produces the assembly. - Moving the static array into global scope. - Changes that caused other strange behaviour, without compiling: - Shortening the array by 30.000 elements (from the original >132.000) caused gcc to exhaust all ram (8GB), take half of the swap (4GB), end up not using the CPU (only ram, went over the 12GB) and after a long while I hit ctrl-c. Note: Compiling takes more than 8GB of ram.
[Bug c++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 --- Comment #2 from Boris Staletic --- > so this time it's not parsing but code-generation that blows up things. That makes sense, when I was playing with the file, it took between 5 to 10 seconds to report syntax errors. Another thing that avoids the ICE is using a "RawCodePoint" with less "std::string"s. Anything else I should try?
[Bug c++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 --- Comment #4 from Boris Staletic --- I get the segmentations fault when running cc1plus directly. No matter if I pass -quiet or not. So what's the next step? Also, I have just noticed "Known to work: 8.1.1". Is that a mistake?
[Bug c++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 --- Comment #8 from Boris Staletic --- > ulimit -s unlimited After running that command and enabling swap, for a total of 16GB available memory, until about 5 minute mark, cc1plus was consuming >4GB. After about five minute mark, cc1plus started consuming memory rapidly, and in about a minute or so, it consumed all 16GB. The end result is OOM killer stopping cc1plus.
[Bug libstdc++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 --- Comment #10 from Boris Staletic --- Running "g++ -S -fno-exceptions CodePoint.cpp" didn't run into OOM killer, but gcc still hanged. The memory usage at maximum was 15.6GB. What I find strange is that "htop" reported the g++ process as dead most of the time and the CPU usage was 20% to 25% (or less) while that was happening.
[Bug libstdc++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 --- Comment #12 from Boris Staletic --- If you're wondering about clang, it hangs too, but doesn't hog memory. > That's to be expected when it runs into swap. Anything else I should try?
[Bug c++/101000] New: ICE when trying to import the absl/container/flat_hash_map.h as a header module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101000
Bug ID: 101000
Summary: ICE when trying to import the
absl/container/flat_hash_map.h as a header module
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris.staletic at gmail dot com
Target Milestone: ---
Steps to repro:
0. Install Abseil from https://github.com/abseil/abseil-cpp
1. g++ -std=c++20 -fmodules-ts -xc++-system-header
absl/container/flat_hash_map.h
2. g++ -std=c++20 -fmodules-ts main.cpp
Output:
In file included from /usr/include/c++/11.1.0/functional:54,
from /usr/include/c++/11.1.0/pstl/glue_algorithm_defs.h:13,
from /usr/include/c++/11.1.0/algorithm:74,
from /usr/include/absl/algorithm/container.h:43,
from /usr/include/absl/container/flat_hash_map.h:38,
of module /usr/include/absl/container/flat_hash_map.h, imported at main.cpp:1:
/usr/include/c++/11.1.0/tuple: In instantiation of ‘constexpr std::pair<_T1,
_T2>::pair(std::piecewise_construct_t, std::tuple<_Args1 ...>,
std::tuple<_Args2 ...>) [with _Args1 = {const int&}; _Args2 = {const int&}; _T1
= std::tuple; _T2 = std::tuple]’:
/usr/include/absl/container/internal/container_memory.h:182:52: required from
‘std::pair, std::tuple >
absl::container_internal::PairArgs(F&&, S&&) [with F = const int&; S = const
int&]’
/usr/include/absl/container/internal/container_memory.h:187:18: required from
‘std::pair, std::tuple >
absl::container_internal::PairArgs(const std::pair<_T1, _T2>&) [with F = int; S
= int]’
/usr/include/absl/container/internal/container_memory.h:207:35: required from
‘decltype
(absl::container_internal::memory_internal::DecomposePairImpl(forward(f),
absl::container_internal::PairArgs((forward)(absl::container_internal::DecomposePair::args)...)))
absl::container_internal::DecomposePair(F&&, Args&& ...) [with F =
absl::container_internal::raw_hash_set, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::EmplaceDecomposable; Args =
{const std::pair&}; decltype
(absl::container_internal::memory_internal::DecomposePairImpl(forward(f),
absl::container_internal::PairArgs((forward)(absl::container_internal::DecomposePair::args)...)))
=
std::pair, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::iterator, bool>]’
/usr/include/absl/container/flat_hash_map.h:580:51: required from ‘static
decltype (absl::container_internal::DecomposePair(declval(),
(declval)()...)) absl::container_internal::FlatHashMapPolicy::apply(F&&, Args&& ...) [with F =
absl::container_internal::raw_hash_set, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::EmplaceDecomposable; Args =
{const std::pair&}; K = int; V = int; decltype
(absl::container_internal::DecomposePair(declval(), (declval)()...)) =
std::pair, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::iterator, bool>]’
/usr/include/absl/container/internal/hash_policy_traits.h:170:20: required
from ‘static decltype (P::apply(forward(f),
(forward)(absl::container_internal::hash_policy_traits >::apply::ts)...))
absl::container_internal::hash_policy_traits
>::apply(F&&, Ts&& ...) [with F =
absl::container_internal::raw_hash_set, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::EmplaceDecomposable; Ts = {const
std::pair&}; P = absl::container_internal::FlatHashMapPolicy; Policy = absl::container_internal::FlatHashMapPolicy;
= void; decltype (P::apply(forward(f),
(forward)(absl::container_internal::hash_policy_traits >::apply::ts)...)) =
std::pair, absl::hash_internal::Hash, std::equal_to,
std::allocator > >::iterator, bool>]’
/usr/include/absl/container/internal/raw_hash_set.h:1129:31: required from
‘std::pair::iterator, bool> absl::container_internal::raw_hash_set::emplace(Args&& ...) [with Args = {const std::pair&};
typename std::enable_if, Hash, Eq, Ts ...>::value,
int>::type = 0; Policy =
absl::container_internal::FlatHashMapPolicy; Hash =
absl::hash_internal::Hash; Eq = std::equal_to; Alloc =
std::allocator >]’
/usr/include/absl/container/internal/raw_hash_set.h:1085:43: required from
‘void absl::container_internal::raw_hash_set::insert(InputIt, InputIt) [with InputIt = const std::pair*;
Policy = absl::container_internal::FlatHashMapPolicy; Hash =
absl::hash_internal::Hash; Eq = std::equal_to; Alloc =
std::allocator >]’
/usr/include/absl/container/internal/raw_hash_set.h:817:11: required from
‘absl::container_internal::raw_hash_set::raw_hash_set(InputIter, InputIter, size_t, const hasher&, const
key_equal&, const allocator_type&) [with InputIter = const std::pair*; Policy = ab
