[Bug libstdc++/71641] New: 22_locale/time_get/get_date/wchar_t/4.cc runs failure if static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71641 Bug ID: 71641 Summary: 22_locale/time_get/get_date/wchar_t/4.cc runs failure if static linking Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: cctsai57 at gmail dot com Target Milestone: --- Hi, I try to simplify the testcase as the following code: ~~ #include #include #include int main() { std::istringstream iss{ "17.12.2003" }; iss.imbue( std::locale{ "de_DE.UTF-8" } ); auto& time_get_facet = std::use_facet>( iss.getloc() ); using iterator_type = std::istreambuf_iterator; iterator_type begin{ iss }; iterator_type end; auto err = std::ios_base::goodbit; std::tm t{}; time_get_facet.get_date( begin, end, iss, err, &t ); // 12/17/2003 if ( err != std::ios_base::eofbit || t.tm_mon != 11 || t.tm_mday != 17 || t.tm_year != 103) __builtin_abort(); } ~~ The default compiler is dyanmic linking and it runs PASS, but FAIL if static linking: $ g++ -std=gnu++11 -static test.cc $ a.out Abort! My Fedora host has de_DE.UTF-8 locale date: $ LC_ALL=de_DE.UTF-8 locale -k -c d_fmt LC_TIME d_fmt="%d.%m.%Y" The following versions of gcc and glibc have the same problem: (1) g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) glibc 2.21 Fedora: Linux 4.4.13-200.fc22.x86_64 (2) g++ (GCC) 6.1.1 20160621 glibc 2.21 (3) arm-linux-gnueabihf-g++ (GCC) 6.1.1 20160623 glibc 2.23
[Bug target/69135] [5/6 Regression][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69135 --- Comment #4 from cctsai57 --- Following gcc/testsuite/gcc.target/arm/{lceil-vcvt_1.c,lfloor-vcvt_1.c,lround-vcvt_1.c}, suggest: /* { dg-do compile } */ /* { dg-require-effective-target arm_v8_vfp_ok } */ /* { dg-options "-O2 -march=armv8-a -ffast-math" } */ /* { dg-add-options arm_v8_vfp } */ int global; void lceil_float (float x, int b) { if (b) global = __builtin_lceilf (x); /* { dg-final { scan-assembler-times "vcvtp.s32.f32\ts\[0-9\]+, s\[0-9\]+" 1 } } */ } void lceil_double (double x, int b) { if (b) global = __builtin_lceil (x); /* { dg-final { scan-assembler-times "vcvtp.s32.f64\ts\[0-9\]+, d\[0-9\]+" 1 } } */ } void lfloor_float (float x, int b) { if (b) global = __builtin_lfloorf (x); /* { dg-final { scan-assembler-times "vcvtm.s32.f32\ts\[0-9\]+, s\[0-9\]+" 1 } } */ } void lfloor_double (double x, int b) { if (b) global = __builtin_lfloor (x); /* { dg-final { scan-assembler-times "vcvtm.s32.f64\ts\[0-9\]+, d\[0-9\]+" 1 } } */ } void lround_float (float x, int b) { if (b) global = __builtin_lroundf (x); /* { dg-final { scan-assembler-times "vcvta.s32.f32\ts\[0-9\]+, s\[0-9\]+" 1 } } */ } void lround_double (double x, int b) { if (b) global = __builtin_lround (x); /* { dg-final { scan-assembler-times "vcvta.s32.f64\ts\[0-9\]+, d\[0-9\]+" 1 } } */ }
[Bug target/69135] New: [5/6][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69135 Bug ID: 69135 Summary: [5/6][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0' Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: cctsai57 at gmail dot com Target Milestone: --- ARMv8 'vcvtp', 'vcvtm' and 'vcvta' do not support conditional execution, but gcc-5/6 for ARMv8 target generate them with conditional execution. See the following steps: ~~ BEGIN ~~ $ cat test.c int global; void lceil_float (float x, int b) { if (b) global = __builtin_lceilf (x); } void lceil_double (double x, int b) { if (b) global = __builtin_lceil (x); } void lfloor_float (float x, int b) { if (b) global = __builtin_lfloorf (x); } void lfloor_double (double x, int b) { if (b) global = __builtin_lfloor (x); } void lround_float (float x, int b) { if (b) global = __builtin_lroundf (x); } void lround_double (double x, int b) { if (b) global = __builtin_lround (x); } $ arm-linux-gnu-gcc -march=armv8-a -mfpu=fp-armv8 -O2 -ffast-math -c test.c /tmp/ccw74V3i.s: Assembler messages: /tmp/ccw74V3i.s:23: Error: instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0' /tmp/ccw74V3i.s:37: Error: instruction cannot be conditional -- `vcvtpne.s32.f64 s0,d0' /tmp/ccw74V3i.s:51: Error: instruction cannot be conditional -- `vcvtmne.s32.f32 s0,s0' /tmp/ccw74V3i.s:65: Error: instruction cannot be conditional -- `vcvtmne.s32.f64 s0,d0' /tmp/ccw74V3i.s:79: Error: instruction cannot be conditional -- `vcvtane.s32.f32 s0,s0' /tmp/ccw74V3i.s:93: Error: instruction cannot be conditional -- `vcvtane.s32.f64 s0,d0' ~~ END ~~ I think this bug is from gcc/config/arm/vfp.md:(define_insn "lsi2"...). I use the following patch to fix it: diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md index c297ed9..f73862e 100644 --- a/gcc/config/arm/vfp.md +++ b/gcc/config/arm/vfp.md @@ -1338,6 +1338,8 @@ "TARGET_HARD_FLOAT && TARGET_FPU_ARMV8 " "vcvt%?.32.\\t%0, %1" [(set_attr "predicable" "no") + (set_attr "predicable_short_it" "no") + (set_attr "conds" "unconditional") (set_attr "type" "f_cvtf2i")] )
[Bug libstdc++/59768] [DR 2219] std::thread constructor not handling reference_wrapper correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59768 cctsai57 changed: What|Removed |Added CC||cctsai57 at gmail dot com --- Comment #6 from cctsai57 --- Hi, Use 'configure CXXFLAGS=-O0' and make gcc successfully, but the generated libstdc++.so has the following problem: ~ BEGIN ~ $ cat test.cc int main() { return 0; } $ g++ test.cc /work2/gcc-x86_64/local/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../lib64/libstdc++.so: undefined reference to `std::_Unwrap, std::decay >::type>::type std::__invfwd >(std::remove_reference >::type&)' collect2: error: ld returned 1 exit status $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/work2/gcc-x86_64/local/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /work2/gcc-x86_64/gcc-src/configure --enable-languages=c,c++ --prefix=/work2/gcc-x86_64/local --disable-bootstrap CXXFLAGS=-O0 Thread model: posix gcc version 6.0.0 20151222 (experimental) (GCC) $ ld -v GNU ld version 2.25-9.fc22 ~END~ I guess that '-O0' causes the '__invfwd' not inlined, and the libstdc++.so building option '-fno-implicit-templates' causes the '__invfwd' template not instantiated. I add 'inline' to '__invfwd' to solve this problem, but I'm not sure if it's right or not: diff --git a/libstdc++-v3/include/std/functional b/libstdc++-v3/include/std/functional index b994df4..9b853e8 100644 --- a/libstdc++-v3/include/std/functional +++ b/libstdc++-v3/include/std/functional @@ -207,7 +207,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION // Used by __invoke_impl instead of std::forward<_Tp> so that a // reference_wrapper is converted to an lvalue-reference. template -typename _Unwrap<_Tp>::type +inline typename _Unwrap<_Tp>::type __invfwd(typename remove_reference<_Tp>::type& __t) noexcept { return _Unwrap<_Tp>::_S_fwd(__t); }
[Bug target/68648] New: [5/6][ARM] ICE: fail to generate BIC(immediate) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68648 Bug ID: 68648 Summary: [5/6][ARM] ICE: fail to generate BIC(immediate) instruction Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: cctsai57 at gmail dot com Target Milestone: --- /* ICE if "arm-linux-gnueabihf-gcc -O1". */ extern void abort (void); int __attribute__((noinline)) foo() { return 123; } int __attribute__((noinline)) bar() { int c = 1; c |= 4294967295 ^ (foo() | 4073709551608); return c; } int main() { if (bar() != 0x83fd4005) abort(); } Compiler version: 5.x, 6.0.0 ICE message: -- $ arm-linux-gnueabihf-gcc -O1 test.c test.c: In function 'bar': test.c:13:1: error: unrecognizable insn: } ^ (insn 27 26 11 2 (set (reg:SI 0 r0 [orig:121 D.4254 ] [121]) (and:SI (not:SI (const_int 1 [0x1])) (reg:SI 0 r0 [orig:121 D.4254 ] [121]))) test.c:12 -1 (nil)) test.c:13:1: internal compiler error: in extract_insn, at recog.c:2343 0x8e52e3 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.c:110 0x8e5319 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.c:118 0x8b9e19 extract_insn(rtx_insn*) ../../gcc/recog.c:2343 0x8b9e81 extract_insn_cached(rtx_insn*) ../../gcc/recog.c:2234 0x6f6a19 cleanup_subreg_operands(rtx_insn*) ../../gcc/final.c:3137 0x8b82cc split_insn ../../gcc/recog.c:2957 0x8bc191 split_all_insns() ../../gcc/recog.c:3011 0x8bc252 rest_of_handle_split_after_reload ../../gcc/recog.c:3958 0x8bc252 execute ../../gcc/recog.c:3987 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. -- Description: I think the above (insn 27 ...) should match arm.md:andsi_notsi_si define_insn pattern but fail because (match_operand 2 ...) does not accept (const_int 1). The following patch may fix this problem and generate "bic r0, r0, #0" successfully. diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md index b380763..0eff5ae 100644 --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -2786,7 +2786,7 @@ (define_insn "andsi_notsi_si" [(set (match_operand:SI 0 "s_register_operand" "=r") - (and:SI (not:SI (match_operand:SI 2 "s_register_operand" "r")) + (and:SI (not:SI (match_operand:SI 2 "reg_or_int_operand" "rI")) (match_operand:SI 1 "s_register_operand" "r")))] "TARGET_32BIT" "bic%?\\t%0, %1, %2"
[Bug libstdc++/67620] New: _GLIBCXX_USE_CXX11_ABI=1 fails to catch ios_base::failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67620 Bug ID: 67620 Summary: _GLIBCXX_USE_CXX11_ABI=1 fails to catch ios_base::failure Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: cctsai57 at gmail dot com Target Milestone: --- #include #include #include using namespace std; int main() { ifstream f; f.exceptions(ifstream::failbit); try { f.open("file_does_not_exit");// throw ios_base::failure } catch (const ios_base::failure &iof) { // g++ -std=gnu++11 -D_GLIBCXX_USE_CXX11_ABI=0 cout << "typeid(iof) : " << typeid(iof).name() << '\n'; } catch (const exception &ex) { // g++ -std=gnu++11 -D_GLIBCXX_USE_CXX11_ABI=1. Bug? Why? cout << "typeid(ex) : " << typeid(ex).name() << '\n'; } } $ g++ -std=gnu++11 -D_GLIBCXX_USE_CXX11_ABI=0 a.cpp -static && ./a.out typeid(iof) : NSt8ios_base7failureE $ g++ -std=gnu++11 -D_GLIBCXX_USE_CXX11_ABI=1 a.cpp -static && ./a.out typeid(ex) : NSt8ios_base7failureE Description: Let `f.open()' throw `ios_base::failure'. If compiled with -D_GLIBCXX_USE_CXX11_ABI=1, the above code fails to catch `ios_base::failure', but `exception' insead. gcc version: gcc version 5.2.1 20150917 (GCC) gcc version 6.0.0 20150917 (experimental) (GCC)
[Bug libstdc++/67600] New: [5/6] Segfault when assigning only one char to ostreambuf_iterator compiled with -O2 or -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67600 Bug ID: 67600 Summary: [5/6] Segfault when assigning only one char to ostreambuf_iterator compiled with -O2 or -O3 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: cctsai57 at gmail dot com Target Milestone: --- #include #include int main() { std::basic_ostringstream ostr; std::ostreambuf_iterator iter(ostr.rdbuf()); *iter++ = 'X'; // Segmentation fault if -O2 or -O3. // *iter++ = 'Y'; // But pass if adding this statement. std::cout << ostr.str() << '\n'; return 0; } Description: If the above simplified code is compiled with -O2 or -O3, segmentation fault happens in "*iter++ = 'x'" statement, but -O0, -O1 or -Os are O.K. If I add the "*iter++ = 'Y'" statement and compile it with -O2 or -O3, it can print "XY" successfully. gcc versions: Fails on gcc-5 (x86_64-redhat-linux on Fedora-22) and gcc-6.0.0 (20150916 (experimental)). Pass on gcc-4.8 and gcc-4.9
[Bug c++/67576] New: expression of typeid( expression ) is evaluated twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67576 Bug ID: 67576 Summary: expression of typeid( expression ) is evaluated twice Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: cctsai57 at gmail dot com Target Milestone: --- #include struct Base { virtual void foo() {} }; // polymorphic int main() { Base b; Base *ary[] = { &b, &b, &b}; int iter = 0; typeid(*ary[iter++]); if (iter != 1)// should be 1 __builtin_abort(); // but 2 return iter; } Compiler version:4.9.x, 5.x, 6.0 Description: The above simplified code would get a wrong `iter' value after typeid statement. It seems to evaluate `iter++' twice. I found that the code has not worked since the following fix: commit cdb704aa83247f82d7b9aae934639a6be2e6681b Author: jason Date: Tue Apr 9 18:11:38 2013 + PR c++/25466 * rtti.c (build_typeid): Check the address of the argument rather than looking for an INDIRECT_REF. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@197644 138bc75d-0d04-0410-961f-82ee72b054a4