[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 Bernd Edlinger changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #25 from Bernd Edlinger --- fixed.
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #24 from Bernd Edlinger --- Author: edlinger Date: Wed Sep 28 12:11:57 2016 New Revision: 240573 URL: https://gcc.gnu.org/viewcvs?rev=240573&root=gcc&view=rev Log: 2016-09-28 Bernd Edlinger PR c++/77748 * g++.dg/pr77550.C: Avoid undefined behavior. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/pr77550.C
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #23 from Christophe Lyon --- Yes, it does the trick. Thanks!
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #22 from Bernd Edlinger --- (In reply to Christophe Lyon from comment #21) > Ha, indeed, that's one of the differences between arm-none-eabi and > arm-none-linux-gnueabi. > > Using -fno-short-enums does make execution succeed, unfortunately the linker > complains because the startup code/libraries are not compiled with this flag: > ld: warning: /tmp/ccKhI9uW.o uses 32-bit enums yet the output is to use > variable-size enums; use of enum values across objects may fail > > Is there an effective-target to check for short-enums? target short_enums but it looks like only checking the diagnostics from the compile not the link. Some use -Wl,--no-enum-size-warning which no other target undestands. Maybe we try this: Index: pr77550.C === --- pr77550.C (revision 240540) +++ pr77550.C (working copy) @@ -1,6 +1,7 @@ // { dg-do run } // { dg-options "-std=c++14 -O3" } +#define enum enum __attribute((mode(SI))) namespace std { typedef int size_t; inline namespace __cxx11 {} @@ -229,15 +230,17 @@ struct _Alloc_hider { _Alloc_hider(pointer, allocator && = allocator()); } _M_dataplus; - size_type _M_string_length; + size_type _M_string_length = 0; enum { _S_local_capacity = 15 } _M_local_buf[_S_local_capacity]; - pointer _M_local_data(); - void _M_set_length(size_type); - basic_string() : _M_dataplus(_M_local_data()) { _M_set_length(0); } + basic_string() : _M_dataplus(0) {} basic_string(const basic_string &) : _M_dataplus(0) {} size_type size() { return _M_string_length; } char *data() const {} }; +//template<> basic_string, std::allocator>:: +//_Alloc_hider::_Alloc_hider(char*, std::allocator&&) {} +extern "C" void +_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_ (...) {} } template int operator==(basic_string<_CharT> &p1, const basic_string<_CharT> &p2) {
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #21 from Christophe Lyon --- Ha, indeed, that's one of the differences between arm-none-eabi and arm-none-linux-gnueabi. Using -fno-short-enums does make execution succeed, unfortunately the linker complains because the startup code/libraries are not compiled with this flag: ld: warning: /tmp/ccKhI9uW.o uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail Is there an effective-target to check for short-enums?
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #20 from Bernd Edlinger --- Bah. Your target defaults to -fshort-enums: that makes the basic_string structure much too short it uses an array of enum to keep it at the same size as the original. Now please try this: Index: pr77550.C === --- pr77550.C (revision 240540) +++ pr77550.C (working copy) @@ -1,5 +1,5 @@ // { dg-do run } -// { dg-options "-std=c++14 -O3" } +// { dg-options "-std=c++14 -O3 -fno-short-enums" } namespace std { typedef int size_t; @@ -229,15 +229,17 @@ struct _Alloc_hider { _Alloc_hider(pointer, allocator && = allocator()); } _M_dataplus; - size_type _M_string_length; + size_type _M_string_length = 0; enum { _S_local_capacity = 15 } _M_local_buf[_S_local_capacity]; - pointer _M_local_data(); - void _M_set_length(size_type); - basic_string() : _M_dataplus(_M_local_data()) { _M_set_length(0); } + basic_string() : _M_dataplus(0) {} basic_string(const basic_string &) : _M_dataplus(0) {} size_type size() { return _M_string_length; } char *data() const {} }; +//template<> basic_string, std::allocator>:: +//_Alloc_hider::_Alloc_hider(char*, std::allocator&&) {} +extern "C" void +_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_ (...) {} } template int operator==(basic_string<_CharT> &p1, const basic_string<_CharT> &p2) {
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-09-27 Ever confirmed|0 |1 --- Comment #19 from Christophe Lyon --- This is not OK yet. I've attached the new .ii, .s and trace files as "v3".
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #18 from Christophe Lyon --- Created attachment 39706 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39706&action=edit qemu trace v3
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #17 from Christophe Lyon --- Created attachment 39705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39705&action=edit assembler-v3
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #16 from Christophe Lyon --- Created attachment 39704 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39704&action=edit preprocessed-v3
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #15 from Bernd Edlinger --- Thanks. Again I could reproduce the issue with the assembler flle. This time it fails in a memcmp. Apparently the _M_string_length is uninitialized, but used in memcmp. Can you try this? Index: pr77550.C === --- pr77550.C (revision 240540) +++ pr77550.C (working copy) @@ -229,15 +229,17 @@ struct _Alloc_hider { _Alloc_hider(pointer, allocator && = allocator()); } _M_dataplus; - size_type _M_string_length; + size_type _M_string_length = 0; enum { _S_local_capacity = 15 } _M_local_buf[_S_local_capacity]; - pointer _M_local_data(); - void _M_set_length(size_type); - basic_string() : _M_dataplus(_M_local_data()) { _M_set_length(0); } + basic_string() : _M_dataplus(0) {} basic_string(const basic_string &) : _M_dataplus(0) {} size_type size() { return _M_string_length; } char *data() const {} }; +//template<> basic_string, std::allocator>:: +//_Alloc_hider::_Alloc_hider(char*, std::allocator&&) {} +extern "C" void +_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_ (...) {} } template int operator==(basic_string<_CharT> &p1, const basic_string<_CharT> &p2) {
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #11 from Christophe Lyon --- Created attachment 39698 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39698&action=edit preprocessed-v2
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #14 from Christophe Lyon --- I've attached the "v2" version of the .ii, .s and trace files.
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #13 from Christophe Lyon --- Created attachment 39700 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39700&action=edit qemu trace v2
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #12 from Christophe Lyon --- Created attachment 39699 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39699&action=edit assembler-v2
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #10 from Bernd Edlinger --- (In reply to Christophe Lyon from comment #9) > Did you try on arm-none-eabi too? > It does not seem to work for me. Hmmm, I don't have the exact environment, but I used your .s file, removed the abi lines, and linked it against the linux, and got immediately a seg-fault, in the _Alloc_hider constructor. That looked like a logical explanation, but it's possible that I still don't understand. Could you try to get a call stack of the seg-fault, with the second patch?
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #9 from Christophe Lyon --- Did you try on arm-none-eabi too? It does not seem to work for me.
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #8 from Andreas Schwab --- That change also makes it run successfully.
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #7 from Bernd Edlinger --- This avoids also the _Alloc_hider constructor. But it still reproduces with gcc-6 and gcc-7. I have found no way to add __attribute((noinline, noclone)) to the template specialization, that works. So I did the dirty trick... It would not have been able to link with gcc-6 because the signature appears to have changed. So that would have been necessary to do anyway. Can you try this please? --- pr77550.C.orig 2016-09-27 10:05:17.812179103 +0200 +++ pr77550.C 2016-09-27 13:08:25.465060583 +0200 @@ -231,13 +231,15 @@ template } _M_dataplus; size_type _M_string_length; enum { _S_local_capacity = 15 } _M_local_buf[_S_local_capacity]; - pointer _M_local_data(); - void _M_set_length(size_type); - basic_string() : _M_dataplus(_M_local_data()) { _M_set_length(0); } + basic_string() : _M_dataplus(0) {} basic_string(const basic_string &) : _M_dataplus(0) {} size_type size() { return _M_string_length; } char *data() const {} }; +//template<> basic_string, std::allocator>:: +//_Alloc_hider::_Alloc_hider(char*, std::allocator&&) {} +extern "C" void +_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_ (...) {} } template int operator==(basic_string<_CharT> &p1, const basic_string<_CharT> &p2) {
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #6 from Andreas Schwab --- On m68k it crashes here: Program received signal SIGSEGV, Segmentation fault. __GI_memcmp (s1=0x0, s2=0x0, len=2285895680) at memcmp.c:333 333 memcmp.c: No such file or directory. (gdb) up #1 0x893c in std::char_traits::compare (p3=, p2=) at ../gcc/testsuite/g++.dg/pr77550.C:221 221 return __builtin_memcmp(0, p2, p3); With the change in #c5 it runs successfully.
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #5 from Bernd Edlinger --- I think the problem is that tree libstdc++ functions are called, but the basic_string structure has been c-reduced. Especially _Alloc_hider, but when that is removed the test case does no longer reproduce the original problem But at least tow externals can be removed easily. Does this work? --- pr77550.C.orig 2016-09-27 10:05:17.812179103 +0200 +++ pr77550.C 2016-09-27 10:13:50.407075199 +0200 @@ -231,9 +231,8 @@ } _M_dataplus; size_type _M_string_length; enum { _S_local_capacity = 15 } _M_local_buf[_S_local_capacity]; - pointer _M_local_data(); - void _M_set_length(size_type); - basic_string() : _M_dataplus(_M_local_data()) { _M_set_length(0); } + pointer _M_local_data() { return 0; } + basic_string() : _M_dataplus(_M_local_data()) {} basic_string(const basic_string &) : _M_dataplus(0) {} size_type size() { return _M_string_length; } char *data() const {}
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #4 from Bernd Edlinger --- Yes. m68k seems to have similar problems: https://gcc.gnu.org/ml/gcc-testresults/2016-09/msg02465.html
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #3 from Christophe Lyon --- Created attachment 39693 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39693&action=edit qemu trace
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #2 from Christophe Lyon --- Created attachment 39692 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39692&action=edit assembler code
[Bug c++/77748] pr77550.C fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 --- Comment #1 from Christophe Lyon --- Created attachment 39691 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39691&action=edit preprocessed file