[Bug libstdc++/39546] New: parallel mode doesn't support implicit string conversion
In parallel mode automatic conversion from string literal to std::string doesn't work when passing literal as parameter to std::find. Woring compiler parameters: g++ test.cpp -o test Failing compiler line: g++ -D_GLIBCXX_PARALLEL -fopenmp -lgomp test.cpp -o test Simple work around is making explicit temporary std::string object. -- Summary: parallel mode doesn't support implicit string conversion Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: suokkos at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion
--- Comment #1 from suokkos at gmail dot com 2009-03-24 16:43 --- Created an attachment (id=17533) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17533&action=view) g++ -v output when trying to compiling in parallel mode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion
--- Comment #2 from suokkos at gmail dot com 2009-03-24 16:46 --- Created an attachment (id=17534) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17534&action=view) --save-temps test.ii from failed compilation in parallel mode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion
--- Comment #3 from suokkos at gmail dot com 2009-03-24 16:48 --- Created an attachment (id=17535) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17535&action=view) Source for the simple test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
[Bug libstdc++/78156] New: constexpr basic_string_view::basic_string_view(const charT *) calls non-constexpr char_traits::length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78156
Bug ID: 78156
Summary: constexpr basic_string_view::basic_string_view(const
charT *) calls non-constexpr char_traits::length
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: suokkos at gmail dot com
Target Milestone: ---
Simple test case fails to compile:
#if __has_include("string_view")
#include
#elif __has_include("experimental/string_view")
#include
namespace std {
using namespace experimental;
}
#endif
constexpr std::string_view foo("bar");
Result with /usr/lib/gcc-snapshot/bin/g++ -c -std=c++17 -Wall test.cc -o test.o
/usr/lib/gcc-snapshot/bin/g++ --version
g++ (Ubuntu 20161006-1ubuntu1) 7.0.0 20161006 (experimental) [trunk revision
240826]
In file included from test.cc:2:0:
test.cc:11:37: in constexpr expansion of
'std::basic_string_view(((const char*)"bar"))'
/usr/lib/gcc-snapshot/include/c++/7.0.0/string_view:100:58: error: call to
non-constexpr function 'static std::size_t std::char_traits::length(const
char_type*)'
: _M_len{__str == nullptr ? 0 : traits_type::length(__str)},
~~~^~~
Related code locations:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/experimental/string_view#L110
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/char_traits.h#L106
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/char_traits.h#L265
Possible fix that would require changes to the standard would changing
std::char_traits::length to be constexpr. I tested that change to my headers
and it works with small changes for this case. I don't know if adding constexpr
will cause any other problems except preventing std::char_traits::length from
calling strlen. But latest version is already using __builtin_strlen.
Does __builtin_strlen pass constexpr test?
Yes. Both gcc and clang managed to compile constexpr with builtin_strlen.
Alternative workarounds would be duplicating std::char_trait implementation
with constexpr alternatives that can be used to make string_view provide
constexpr constructor.
[Bug libstdc++/78156] constexpr basic_string_view::basic_string_view(const charT *) calls non-constexpr char_traits::length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78156 --- Comment #2 from Pauli --- Maybe this isn't exactly defect. But constexpr is hard beast to get right in any code. For user code simplest workaround would be remembering to use operator""sv everywhere. Too bad accessing those operator seems to be hard. I guess I need configure time check for that and provide my own fallback if the sv operator is missing.
[Bug c++/64735] std::future broken on armel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735 Pauli changed: What|Removed |Added CC||suokkos at gmail dot com --- Comment #7 from Pauli --- Created attachment 39971 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39971&action=edit Not yet fully tested patch for std::future fix I'm currently in process fixing this bug. But I have to delay running tests and other verification for tomorrow. The patch is compile tested on Debian armel vm.
[Bug libstdc++/78156] constexpr basic_string_view::basic_string_view(const charT *) calls non-constexpr char_traits::length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78156
--- Comment #3 from Pauli ---
Could __builtin_constant_p help to select different code for compile time and
runtime?
Something like:
string_view(const _CharT* __str) :
_M_len(/*null check*/__builtin_constant_p(__str /*or __str[0]?*/) ?
recursive_strlen<_CharT>(__str) : /*or
traits_type::__constexpr_length()*/
traits_type::length()),
_M_str(__str)
{}
[Bug c/78233] New: compute_idf fails quick_push size check when compiling libgcc for Debian armel with qemu-arm-static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78233 Bug ID: 78233 Summary: compute_idf fails quick_push size check when compiling libgcc for Debian armel with qemu-arm-static Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: suokkos at gmail dot com Target Milestone: --- Created attachment 39980 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39980&action=edit libgcc2.i from xgcc Same source compiled fine with amd64 native tools. GCC tested are: 1. xgcc (GCC) 7.0.0 20161105 (experimental) (github: trunk@241870) 2. gcc (Debian 6.2.0-11) 6.2.0 20161103 System: /usr/bin/qemu-arm-static Debian sid chroot Configure: 1. ../configure That resulted to config.status including --enable-languages=c,c++,fortran,lto,objc 2. About PATH=/home/coren/project/gcc-6-6.2.0/bin:/usr/lib/arm-linux-gnueabi/gcc/bin:/home/coren/bin:/opt/wine-staging/bin:/usr/local/bin:/usr/bin:/bin CC=arm-linux-gnueabi-gcc-6 CXX=arm-linux-gnueabi-g++-6 LDFLAGS_FOR_TARGET=-Wl,-z,relro LD_LIBRARY_PATH=/home/coren/project/gcc-6-6.2.0/build/gcc/ada/rts ../configure -v --with-pkgversion='Debian 6.2.0-10' --with-bugurl='file:///usr/share/doc/gcc-6/README.Bugs' --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=arm-linux-gnueabi- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armel/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armel --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armel --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv4t --with-float=soft --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Command to trigger the bug: /home/coren/project/gcc/buildarmel/./gcc/xgcc -B/home/coren/project/gcc/buildarmel/./gcc/ -B/usr/local/armv7l-unknown-linux-gnueabi/bin/ -B/usr/local/armv7l-unknown-linux-gnueabi/lib/ -isystem /usr/local/armv7l-unknown-linux-gnueabi/include -isystem /usr/local/armv7l-unknown-linux-gnueabi/sys-include-g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -fno-inline -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include-o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS Backtrace from error: #12 0x00eca52c in fancy_abort(char const*, int, char const*) () #13 0x002e15c4 in compute_idf(bitmap_head*, bitmap_head*) () #14 0x007d5070 in (anonymous namespace)::pass_build_ssa::execute(function*) () #15 0x00665db4 in execute_one_pass(opt_pass*) () Compiler error: ../../../libgcc/libgcc2.c: In function ‘__muldi3’: ../../../libgcc/libgcc2.c:557:1: internal compiler error: in quick_push, at vec.h:863 } ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug middle-end/78233] compute_idf fails quick_push size check when compiling libgcc for Debian armel with qemu-arm-static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78233 --- Comment #1 from Pauli --- Sorry. Error in original report: gcc (Debian 6.2.0-11) 6.2.0 20161103 with command: gcc -isystem /usr/local/armv7l-unknown-linux-gnueabi/include -isystem /usr/local/armv7l-unknown-linux-gnueabi/sys-include-g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -fno-inline -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include-o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS works fine. I forgot that actual compile job is separate process when testing system gcc. On amd64 host: /home/coren/project/gcc/buildamd64/./gcc/xgcc -B/home/coren/project/gcc/buildamd64/./gcc/ -isystem /usr/local/armv7l-unknown-linux-gnueabi/include -isystem /usr/local/armv7l-unknown-linux-gnueabi/sys-include-g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -fno-inline -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include-o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /home/coren/project/gcc/buildarmel/armv7l-unknown-linux-gnueabi/libgcc/libgcc2.i -fvisibility=hidden -DHIDE_EXPORTS works fine. Too bad compile cycle for armel is very long (about 30 hours) making it very annoying that cc1 doesn't have debug symbols.
[Bug libstdc++/64735] std::future broken on armel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735 --- Comment #9 from Pauli --- atomicity.h uses exactly same builtins if _GLIBCXX_ATOMIC_BUILTINS is set 1. Difference include check for __gthread_active_p check and annotations for race detector. Annotations are empty macros in default build. Same code is uses for all other atomic operations in libstdc++. I'm finally having an working armv5te build from gcc-6-branch. I'm currently waiting the second unit test run to complete. If there is no unexpected failures from futures or exceptions I fill submit the complete patch later today.
