diff mbox

Fix undefined behavior on g++.dg/pr77550.C (PR 77748)

Message ID AM4PR0701MB21627C6F0B47BB949EA48570E4CF0@AM4PR0701MB2162.eurprd07.prod.outlook.com
State New
Headers show

Commit Message

Bernd Edlinger Sept. 28, 2016, 10:22 a.m. UTC
Hi,

in this test case, c-reduce had created various forms of undefined
behaviour, which did only show up on m68k and arm-none-eabi.

Most notably the original problem did only happen when
512/sizeof(basic_string) = 7, but with a non-zero remainder.
In the way that c-reduce used to reduce that structure
there is an array of enum as a place holder.
But that depends on sizeof(enum) to be 4, which is
not the case on arm-none-eabi.

Other problems come from a not-initialized _M_string_length
which ends up in a memcmp crash.

And the _Alloc_hider constructor, which is linked to
libstdc++, but that works only as long as the signature
of that function is not changed, so it turned out
the test case would not link with gcc-6 for instance.

I found no way how to write that template specialization
without breaking the purpose of reproducing the
original PR, because __attribute((noinline, noclone))
seems to be completely ignored in this case.

I made sure that PR 77550 can still be reproduced
with this test case both on gcc-6 and trunk.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.

Comments

Richard Biener Sept. 28, 2016, 10:34 a.m. UTC | #1
On Wed, 28 Sep 2016, Bernd Edlinger wrote:

> Hi,
> 
> in this test case, c-reduce had created various forms of undefined
> behaviour, which did only show up on m68k and arm-none-eabi.
> 
> Most notably the original problem did only happen when
> 512/sizeof(basic_string) = 7, but with a non-zero remainder.
> In the way that c-reduce used to reduce that structure
> there is an array of enum as a place holder.
> But that depends on sizeof(enum) to be 4, which is
> not the case on arm-none-eabi.
> 
> Other problems come from a not-initialized _M_string_length
> which ends up in a memcmp crash.
> 
> And the _Alloc_hider constructor, which is linked to
> libstdc++, but that works only as long as the signature
> of that function is not changed, so it turned out
> the test case would not link with gcc-6 for instance.
> 
> I found no way how to write that template specialization
> without breaking the purpose of reproducing the
> original PR, because __attribute((noinline, noclone))
> seems to be completely ignored in this case.
> 
> I made sure that PR 77550 can still be reproduced
> with this test case both on gcc-6 and trunk.
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?

Yes.

Thanks,
Richard.

> 
> Thanks
> Bernd.
diff mbox

Patch

2016-09-28  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	PR c++/77748
	* g++.dg/pr77550.C: Avoid undefined behavior.

ndex: 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<char> && = allocator<char>());
   } _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<char, std::char_traits<char>, std::allocator<char>>::
+//_Alloc_hider::_Alloc_hider(char*, std::allocator<char>&&) {}
+extern "C" void
+_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_ (...) {}
 }
 template <typename _CharT>
 int operator==(basic_string<_CharT> &p1, const basic_string<_CharT> &p2) {