[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
