[Bug middle-end/64922] New: runtime error: member call on misaligned address for type 'struct _Rep'

[Bug middle-end/64922] New: runtime error: member call on misaligned address for type 'struct _Rep'

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

            Bug ID: 64922
           Summary: runtime error: member call on misaligned address for
                    type 'struct _Rep'
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mpolacek at gcc dot gnu.org

Compile x.cc with -fsanitize=alignment,bool,enum -O2
-D_GLIBCXX_USE_CXX11_ABI=0.  Then run the generated binary:

$ ./a.out d_mos1.model
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:2941:9:
runtime error: member call on misaligned address 0xffffffffffffffe9 for type
'struct _Rep', which requires 8 byte alignment
0xffffffffffffffe9: note: pointer points here
<memory cannot be printed>
Segmentation fault (core dumped)

That runtime error seems like a bug.  Note that the failure goes away with e.g.
-fno-tree-fre.  Without -fsanitize=... it doesn't even segfault, which is what
makes this bug extremely hard to analyze.  Also I haven't manage to reduce the
test case more.

$ cat d_mos1.model
/**/
$ cat x.cc
#include <string>
class CS_FILE {};
class CS {
private:
  char* _name;
  char* _cmd;
  int  _cnt;
  bool _ok;
  int  _length;
  static enum MATCH_STYLE {msPARTIAL, msIGNORE_CASE, msEXACT} _ms;
public:
  explicit    CS(CS_FILE, const std::string& name, int i=0);
  int          cursor()const    {return _cnt;}
  bool        stuck(int* last)    {bool ok=*last<_cnt; *last=_cnt; return !ok;}
        operator bool()const{return _ok;}
  char          peek()const    {return _cmd[_cnt];}
  bool          ns_more()const    {return peek()!='\0';}
  CS&          dmatch(const std::string&);
  bool          match1(char c)const{return (peek()==c);}
  CS&          skip(int c=1)    {_cnt+=c; _ok=_cnt<=_length; return *this;}
  CS&          skipbl();
  CS&          skip1b(char);
  CS&          skip1(char);
  CS&          skipto1(char);
  CS&          operator>>(const char x)    {return skip1b(x);}
};    
template <class T>
inline bool get(CS& cmd, const std::string& key, T* val)
{
  if (cmd.dmatch(key)) {
    cmd >> '=' >> *val;
    return true;
  }
  return false;
}
template <class T>
inline CS& operator>>(CS& cmd, T& val)
{
  val.parse(cmd);
  return cmd;
}
class Base;
class Code_Block;
class Head;
class File;
class CS;
class Base
{
public:
  virtual void parse(CS&) = 0;
  virtual ~Base() {}
};
class Code_Block
  :public Base
{
  const char* _begin;
  const char* _end;
public:
  void parse(CS& f);
  Code_Block() :_begin(0), _end(0) {}
};
class Head
  :public Base
{
public:
  void parse(CS& f);
};
class File
{
  std::string    _name;
  CS        _file;
  Head        _head;
  Code_Block    _h_headers;
public:
  File(const std::string& file_name);
};
void Code_Block::parse(CS& file) 
{
  file.skipbl().skip1('{');
}
void Head::parse(CS& file)
{
  file.skipto1('*');
}
File::File(const std::string& file_name)
  :_name(file_name),
   _file(CS_FILE(), file_name)
{
  get(_file, "foo", &_head);
  int here = _file.cursor();
  for (;;) {
      get(_file, "X", &_h_headers)
      || get(_file, "X", &_h_headers)
      || get(_file, "X", &_h_headers)
      ;
    if (_file.stuck(&here))
      break;
  }
}
CS::MATCH_STYLE CS::_ms(msPARTIAL);
CS& CS::dmatch(const std::string& s)
{
  asm ("": "+r" (_ms));
  return *this;
}
CS::CS(CS_FILE, const std::string& name, int i)
  :_name(0),
   _cmd(0),
   _cnt(i),
   _ok(true),
   _length(0)
{
  _name = new char[name.length()+1];
  __builtin_strcpy(_name, name.c_str());
  _length = 1;
  _cmd = new char[_length+2];
  _cmd[_length++] = '\0';
}
CS& CS::skipbl()
{
  while (peek() && (!isgraph(peek())))
    skip();
  return *this;
}
CS& CS::skip1b(char t)
{
  return *this;
}
CS& CS::skip1(char t)
{
  if (match1(t))
    skip();
  return *this;
}
CS& CS::skipto1(char c)
{
  while (ns_more() && !match1(c))
    skip();
  return *this;
}
int main(int argc, char** argv)
{
  File f(argv[1]);
}

[Bug middle-end/64922] runtime error: member call on misaligned address for type 'struct _Rep'

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
It might have started with r219695.  Or maybe with r219823.

[Bug middle-end/64922] runtime error: member call on misaligned address for type 'struct _Rep'

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Program received signal SIGSEGV, Segmentation fault.
0x00000000004018e7 in __exchange_and_add (__val=-1, __mem=0xfffffffffffffff9)
    at
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/atomicity.h:49
49      { return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
(gdb) bt
#0  0x00000000004018e7 in __exchange_and_add (__val=-1,
__mem=0xfffffffffffffff9)
    at
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/atomicity.h:49
#1  __exchange_and_add_dispatch (__val=-1, __mem=0xfffffffffffffff9)
    at
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/atomicity.h:82
#2  _M_dispose (__a=..., this=0xffffffffffffffe9)
    at
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:2639
#3  ~basic_string (this=0x7fffffffde70, __in_chrg=<optimized out>)
    at
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:2941
#4  File::File (this=0x7fffffffdf10, file_name=...) at x.cc:89
#5  0x0000000000400c49 in main (argc=<optimized out>, argv=0x7fffffffe058) at
x.cc:143

[Bug middle-end/64922] runtime error: member call on misaligned address for type 'struct _Rep'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
My current understanding is that the std::string "foo" temporary is
constructed, then destructed, then a store to here is performed (where here
shares the stack slot with std::string "foo" temporary), and then for some
reason the std:;string temporary is destructed again.

[Bug middle-end/64922] runtime error: member call on misaligned address for type 'struct _Rep'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-03
                 CC|                            |hubicka at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Goes away with -fno-devirtualize or -fno-devirtualize-speculatively.
Looking at the dumps, after IPA we have:
  [pol6.C:39:3] Head::parse (_33, _30);
call (looks fine), but instead of the 3 expected
  [pol6.C:39:3] Code_Block::parse (_36, _30);
  [pol6.C:39:3] Code_Block::parse (_36, _30);
  [pol6.C:39:3] Code_Block::parse (_36, _30);
calls that show e.g. with -fno-devirtualize-speculatively we instead have:
  [pol6.C:39:3] __builtin_unreachable (_36, _30);
  [pol6.C:39:3] __builtin_unreachable (_36, _30);
  [pol6.C:39:3] __builtin_unreachable (_36, _30);
and no wonder everything goes wrong afterwards.
I don't see why IPA devirtualization thinks something is wrong on the
Code_Block::parse calls.  And, because for these __builtin_unreachable calls
IPA doesn't strip the undesirable arguments, it isn't transformed even with
-fsanitize=undefined into __ubsan_handle_unreachable (), which would make it
far easier to figure this out.

Honza, can you please have a look?

[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |hubicka at gcc dot gnu.org

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Yes, I will take a look. Removal of args is still on my TODO list :(

[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Created attachment 34666
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34666&action=edit
Patch I am testing.

The following patch fixes the parameters, but I do not get any
ubsan_unreachable calls. Jakub, can you take a look, please?

[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #6)
> Created attachment 34666 [details]
> Patch I am testing.
> 
> The following patch fixes the parameters, but I do not get any
> ubsan_unreachable calls. Jakub, can you take a look, please?

Have you compiled the testcase with -fsanitize=alignment,bool,enum -O2
-D_GLIBCXX_USE_CXX11_ABI=0 , against recentish libstdc++ headers?

[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, with the patch you've posted I get:
$ /usr/src/gcc/obj/gcc/g++ -B /usr/src/gcc/obj/gcc/
`/usr/src/gcc/obj/x86_*/libstdc++-v3/scripts/testsuite_flags --build-includes`
-E -o x.ii x.cc -O2 -D_GLIBCXX_USE_CXX11_ABI=0
$ /usr/src/gcc/obj/gcc/cc1plus -fsanitize=alignment,bool,enum,unreachable -O2
x.ii  -quiet
$ gcc -o x x.s
/usr/src/gcc/obj/x86_64-unknown-linux-gnu/libsanitizer/ubsan/.libs/libubsan.a
-lpthread -ldl
/usr/src/gcc/obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so
-Wl,-rpath,/usr/src/gcc/obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/
$ ./pol6 a
x.cc:39:3: runtime error: execution reached a __builtin_unreachable() call

And the unreachable calls in there are IMHO wrong.

[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #8)
> So, with the patch you've posted I get:
> $ /usr/src/gcc/obj/gcc/g++ -B /usr/src/gcc/obj/gcc/
> `/usr/src/gcc/obj/x86_*/libstdc++-v3/scripts/testsuite_flags
> --build-includes` -E -o x.ii x.cc -O2 -D_GLIBCXX_USE_CXX11_ABI=0
> $ /usr/src/gcc/obj/gcc/cc1plus -fsanitize=alignment,bool,enum,unreachable
> -O2 x.ii  -quiet
> $ gcc -o x x.s
> /usr/src/gcc/obj/x86_64-unknown-linux-gnu/libsanitizer/ubsan/.libs/libubsan.
> a -lpthread -ldl
> /usr/src/gcc/obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.
> so
> -Wl,-rpath,/usr/src/gcc/obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/
> $ ./pol6 a
> x.cc:39:3: runtime error: execution reached a __builtin_unreachable() call
> 
> And the unreachable calls in there are IMHO wrong.

/g++ -> /xg++
./pol6 -> ./x

Sorry, for the typos.

[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34669
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34669&action=edit
x.ii

Preprocessed source.

[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Wed Feb  4 20:28:49 2015
New Revision: 220417

URL: https://gcc.gnu.org/viewcvs?rev=220417&root=gcc&view=rev
Log:

    PR middle-end/64922
    * gimple.c: Include gimple-ssa.h.
    (maybe_remove_unused_call_args): New function.
    * gimple.h (maybe_remove_unused_call_args): Declare.
    * cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Use it.
    * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Likewise.
    * gimple-fold.c (gimple_fold_call): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cgraph.c
    trunk/gcc/gimple-fold.c
    trunk/gcc/gimple.c
    trunk/gcc/gimple.h
    trunk/gcc/tree-ssa-pre.c

[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

--- Comment #12 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, the devirtualization I see is for
_Z3getI10Code_BlockEbR2CSRKSsPT_.part.3.constprop.7
when it is inlined to
_ZN4FileC2ERKSs


outer type of original context is:

$6 = {offset = 0, speculative_offset = 0, outer_type = 0x7ffff631f498,
speculative_outer_type = 0x0, maybe_in_construction = 0, maybe_derived_type =
1, 

where outer_type is Code_Block. It gets combined with:

$10 = {offset = 0, speculative_offset = 0, outer_type = 0x7ffff6cb0000,
speculative_outer_type = 0x0, maybe_in_construction = 0, maybe_derived_type =
0, 
  speculative_maybe_derived_type = 0, invalid = 0, dynamic = 1}

where outer_type is basic_string

These two types are not related, so we go for invalid.  The first type is
derived from fact that operator >> takes reference to Code_Block that seems OK.

The other is determined by

  std::basic_string<char>::basic_string (&D.13149, "X", &D.13150);              

that is passed to 

  _62 = get<Code_Block> (_30, &D.13149, _36);                                   

So I think we confuse argument 2 of get<Code_Block> with argument 1 of
get<Code_Block>.part.3.

[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

--- Comment #13 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Created attachment 34671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34671&action=edit
Patch I am testing

OK, the problem is that we first speculatively devirtualize to the target while
inlining. Martin's ipa-prop code does not expect that and forgets to update
parm_index of the call to reflect effect of inlining (it was written expecting
only full devirt)

[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

--- Comment #14 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Wed Feb  4 22:59:30 2015
New Revision: 220423

URL: https://gcc.gnu.org/viewcvs?rev=220423&root=gcc&view=rev
Log:
    PR middle-end/64922
    * ipa-prop.c (update_indirect_edges_after_inlining): Correctly update
    edges that become speculative.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-prop.c

[Bug middle-end/64922] [5 Regression] runtime error: member call on misaligned address for type 'struct _Rep'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64922

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.