[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<std::time_get>( 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, );
// 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::reference_wrapper,
std::decay<std::reference_wrapper >::type>::type
std::__invfwd<std::reference_wrapper
>(std::remove_reference<std::reference_wrapper >::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 )
{
// g++ -std=gnu++11 -D_GLIBCXX_USE_CXX11_ABI=0
cout << "typeid(iof) : " << typeid(iof).name() << '\n';
}
catch (const exception )
{
// 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[] = { , , };
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 <jason@138bc75d-0d04-0410-961f-82ee72b054a4>
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
