public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf
@ 2015-02-27 10:21 doko at gcc dot gnu.org
  2015-02-27 10:32 ` [Bug target/65233] " rguenth at gcc dot gnu.org
                   ` (20 more replies)
  0 siblings, 21 replies; 22+ messages in thread
From: doko at gcc dot gnu.org @ 2015-02-27 10:21 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 65233
           Summary: [5 Regression] ICE (segfault) on arm-linux-gnueabihf
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org

seen when building ardour on armhf, r220999

$ g++ -c -O3 audio_track.ii
audio_track.ii: In function 'void export_stuff()':
audio_track.ii:71:6: internal compiler error: Segmentation fault
 void export_stuff() {
      ^
Please submit a full bug report,
with preprocessed source if appropriate.

(gdb) bt
#0  0x005ebd8e in integer_zerop(tree_node const*) ()
#1  0x003a1a2e in walk_ssa_copies(tree_node*, hash_set<tree_node*,
default_hashset_traits>**) ()
#2  0x003a27a0 in
ipa_polymorphic_call_context::ipa_polymorphic_call_context(tree_node*,
tree_node*, gimple_statement_base*, tree_node**) ()
#3  0x0034f028 in fold_stmt_1(gimple_stmt_iterator*, bool, tree_node*
(*)(tree_node*)) ()
#4  0x004c9070 in replace_uses_by(tree_node*, tree_node*) ()
#5  0x004c9554 in gimple_merge_blocks(basic_block_def*, basic_block_def*) ()
#6  0x0028242c in merge_blocks(basic_block_def*, basic_block_def*) ()
#7  0x004ce264 in cleanup_tree_cfg_bb(basic_block_def*) ()
#8  0x004ce6d8 in cleanup_tree_cfg() ()
#9  0x00432232 in execute_function_todo(function*, void*) ()
#10 0x004326b8 in execute_todo(unsigned int) ()
#11 0x00433f88 in execute_one_pass(opt_pass*) ()
#12 0x00434220 in execute_pass_list_1(opt_pass*) [clone .constprop.59] ()
#13 0x0043422a in execute_pass_list_1(opt_pass*) [clone .constprop.59] ()
#14 0x00434258 in execute_pass_list(function*, opt_pass*) ()
#15 0x00298a2a in cgraph_node::expand() ()
#16 0x0029a4b0 in symbol_table::compile() [clone .part.42] ()
#17 0x0029a6ec in symbol_table::finalize_compilation_unit() ()
#18 0x001a3210 in cp_write_global_declarations() ()
#19 0x004a916a in compile_file() ()
#20 0x00156ec2 in toplev::main(int, char**) ()
#21 0x00157914 in main ()

$ cat audio_track.ii
template <class> class A;
class B;
struct C {
  A<B> &operator*();
};
int a;
class D {
public:
  virtual void m_fn1() {}
  void m_fn2() { m_fn1(); }
};

class shared_count {
  D *pi_;

public:
  shared_count() : pi_() {}
  ~shared_count() {
    if (pi_)
      pi_->m_fn2();
  }
  shared_count(shared_count const &p1) : pi_(p1.pi_) {
    if (pi_)
      __sync_fetch_and_add(&a, 1);
  }
  void m_fn3(shared_count &p1) {
    D *b = p1.pi_;
    p1.pi_ = pi_;
    pi_ = b;
  }
};

class G;
struct F {
  typedef G *type;
};
template <class T> class A {
  typedef A this_type;

public:
  typedef T element_type;
  A() {}
  template <class Y> A(A<Y> &p1, element_type *p2) : px(p2), pn(p1.pn) {}
  A &operator=(A p1) {
    this_type(p1).m_fn5(*this);
    return *this;
  }
  element_type *m_fn4();
  typedef element_type *this_type::*unspecified_bool_type;
  operator unspecified_bool_type() { return px ? 0 : &this_type::px; }
  void m_fn5(A &p1) {
    p1.px = px;
    pn.m_fn3(p1.pn);
  }
  element_type *px;
  shared_count pn;
};

template <class, class U> A<G> dynamic_pointer_cast(A<U> &p1) {
  G *p = dynamic_cast<G *>(p1.m_fn4());
  return p ? A<G>(p1, p) : A<G>();
}

class B {
public:
  void m_fn7();
  virtual void m_fn6();
};
class G : public B {};
F::type c;
void export_stuff() {
  C i;
  for (;;) {
    A<G> d;
    if (d = dynamic_pointer_cast<G>(*i))
      c->m_fn7();
  }
}


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
@ 2015-02-27 10:32 ` rguenth at gcc dot gnu.org
  2015-02-27 10:41 ` ktkachov at gcc dot gnu.org
                   ` (19 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-02-27 10:32 UTC (permalink / raw)
  To: gcc-bugs

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
                 CC|                            |hubicka at gcc dot gnu.org
   Target Milestone|---                         |5.0


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
  2015-02-27 10:32 ` [Bug target/65233] " rguenth at gcc dot gnu.org
@ 2015-02-27 10:41 ` ktkachov at gcc dot gnu.org
  2015-02-27 10:53 ` doko at gcc dot gnu.org
                   ` (18 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: ktkachov at gcc dot gnu.org @ 2015-02-27 10:41 UTC (permalink / raw)
  To: gcc-bugs

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-02-27
                 CC|                            |ktkachov at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Can't reproduce with r221043.
Can you provide the gcc config options?


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
  2015-02-27 10:32 ` [Bug target/65233] " rguenth at gcc dot gnu.org
  2015-02-27 10:41 ` ktkachov at gcc dot gnu.org
@ 2015-02-27 10:53 ` doko at gcc dot gnu.org
  2015-02-27 11:46 ` jakub at gcc dot gnu.org
                   ` (17 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: doko at gcc dot gnu.org @ 2015-02-27 10:53 UTC (permalink / raw)
  To: gcc-bugs

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #2 from Matthias Klose <doko at gcc dot gnu.org> ---
Configured with: -v
     --with-pkgversion='Ubuntu 5-20150227-1ubuntu11'
     --with-bugurl='file:///usr/share/doc/gcc-5/README.Bugs'
     --enable-languages=c,c++,java,go,fortran,objc,obj-c++
     --prefix=/usr
     --program-suffix=-5
     --enable-shared
     --enable-linker-build-id
     --libexecdir=/usr/lib
     --without-included-gettext
     --enable-threads=posix
     --with-gxx-include-dir=/usr/include/c++/5
     --libdir=/usr/lib
     --enable-nls
     --with-sysroot=/
     --enable-clocale=gnu
     --enable-libstdcxx-debug
     --enable-libstdcxx-time=yes
     --with-default-libstdcxx-abi=c++98
     --enable-gnu-unique-object
     --disable-libitm
     --disable-libquadmath
     --enable-plugin
     --with-system-zlib
     --disable-browser-plugin
     --enable-java-awt=gtk
     --enable-gtk-cairo
     --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf/jre
     --enable-java-home
     --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf
     --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf
     --with-arch-directory=arm
     --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
     --enable-objc-gc
     --enable-multiarch
     --enable-multilib
     --disable-sjlj-exceptions
     --with-arch=armv7-a
     --with-fpu=vfpv3-d16
     --with-float=hard
     --with-mode=thumb
     --disable-werror
     --enable-multilib
     --enable-checking=release
     --build=arm-linux-gnueabihf
     --host=arm-linux-gnueabihf
     --target=arm-linux-gnueabihf


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2015-02-27 10:53 ` doko at gcc dot gnu.org
@ 2015-02-27 11:46 ` jakub at gcc dot gnu.org
  2015-02-27 12:05 ` doko at gcc dot gnu.org
                   ` (16 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-02-27 11:46 UTC (permalink / raw)
  To: gcc-bugs

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

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> ---
Can't reproduce either (with cross-compiler from x86_64-linux).
-O3 pr65233.C -quiet -nostdinc  -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard
-mthumb
is what I've tried after -O3 pr65233.C failed to ICE, but no ICE either.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2015-02-27 11:46 ` jakub at gcc dot gnu.org
@ 2015-02-27 12:05 ` doko at gcc dot gnu.org
  2015-02-27 12:07 ` jakub at gcc dot gnu.org
                   ` (15 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: doko at gcc dot gnu.org @ 2015-02-27 12:05 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Matthias Klose <doko at gcc dot gnu.org> ---
does adding -fstack-protector-strong make a difference?


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2015-02-27 12:05 ` doko at gcc dot gnu.org
@ 2015-02-27 12:07 ` jakub at gcc dot gnu.org
  2015-02-27 20:31 ` aldyh at gcc dot gnu.org
                   ` (14 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-02-27 12:07 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2015-02-27 12:07 ` jakub at gcc dot gnu.org
@ 2015-02-27 20:31 ` aldyh at gcc dot gnu.org
  2015-03-01  8:59 ` doko at gcc dot gnu.org
                   ` (13 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: aldyh at gcc dot gnu.org @ 2015-02-27 20:31 UTC (permalink / raw)
  To: gcc-bugs

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |aldyh at gcc dot gnu.org
         Resolution|---                         |WORKSFORME

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Cannot reproduce either.  I am on a cross from x86-64 with:

--enable-languages=c,c++ --disable-bootstrap   --enable-shared --disable-libitm
--disable-libquadmath  --enable-multiarch --enable-multilib
--disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16
--with-float=hard --with-mode=thumb --disable-multilib
--enable-checking=release --target=arm-linux-gnueabihf 

The option -fstack-protector-strong does not make a difference either.

Closing.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2015-02-27 20:31 ` aldyh at gcc dot gnu.org
@ 2015-03-01  8:59 ` doko at gcc dot gnu.org
  2015-03-01 10:18 ` [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu doko at gcc dot gnu.org
                   ` (12 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: doko at gcc dot gnu.org @ 2015-03-01  8:59 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Matthias Klose <doko at gcc dot gnu.org> ---
this is the testcase from ardour3:

$ g++ -c -g -O3 -fPIC track3.ii    
track3.ii: In member function 'void F::apply(void (Track::*)(T, void*), T,
void*) [with T = bool]':
track3.ii:108:1: internal compiler error: Segmentation fault
 F::apply (void (Track::*p1) (T, void *), T p2, void *)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

$ cat track3.ii
namespace std
{
template < typename _Tp > void swap (_Tp p1, _Tp & p2)
{
    p2 = p1;
} template < typename _Tp > struct A
{
    _Tp & operator* ();
};
template < typename _Tp > class B
{
public:
    typedef A < _Tp > iterator;
};
}

int a;
class C
{
    int use_count_;
public:
    virtual void destroy ();
    void release ()
    {
        if (use_count_)
            destroy ();
    }
};
class shared_count
{
    C *pi_;
public:
    shared_count ():pi_ ()
    {
    }
    ~shared_count ()
    {
        if (pi_)
            pi_->release ();
    }
    shared_count (shared_count const &p1):pi_ (p1.pi_)
    {
        if (pi_)
            __sync_fetch_and_add (&a, 1);
    }
    void swap (shared_count & p1)
    {
        C *b = p1.pi_;
        p1.pi_ = pi_;
        pi_ = b;
    }
};

template < class T > class D
{
    typedef D this_type;
public:
    typedef T element_type;
    D ()
    {
    } template < class Y > D (D < Y > p1, element_type * p2):px (p2),
    pn (p1.pn)
    {
    } D & operator= (D p1)
    {
        this_type (p1).swap (*this);
        return *this;
    }
    element_type *get ()
    {
    }
    typedef element_type *this_type::*unspecified_bool_type;
    operator      unspecified_bool_type ()
    {
        return px ? 0 : &this_type::px;
    }
    void swap (D & p1)
    {
        std::swap (px, p1.px);
        pn.swap (p1.pn);
    } element_type *px;
    shared_count pn;
};

class Track;
template < class, class U > D < Track > dynamic_pointer_cast (D < U > &p1)
{
    Track *p;
    return p ? D < Track > (p1, p) : D < Track > ();
}

class F
{
public:
    template < class T > void apply (void (Track::*)(T, void *), T,
                                     void *);
};
class G
{
protected:
    F _route_group;
};
class Track:G
{
    void prep_record_enabled (bool, void *);
};
template < class T > void
F::apply (void (Track::*p1) (T, void *), T p2, void *)
{
    for (std::B < D < int > >::iterator i;;)
    {
        D < Track > c;
        if (c = dynamic_pointer_cast < Track > (*i))
            (c.get ()->*p1) (p2, this);
    }
}

void
Track::prep_record_enabled (bool p1, void *)
{
    _route_group.apply (&Track::prep_record_enabled, p1, &_route_group);
}


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (7 preceding siblings ...)
  2015-03-01  8:59 ` doko at gcc dot gnu.org
@ 2015-03-01 10:18 ` doko at gcc dot gnu.org
  2015-03-01 10:19 ` doko at gcc dot gnu.org
                   ` (11 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: doko at gcc dot gnu.org @ 2015-03-01 10:18 UTC (permalink / raw)
  To: gcc-bugs

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|arm-linux-gnueabihf         |arm-linux-gnueabihf,
                   |                            |aarch64-linux-gnu
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WORKSFORME                  |---
            Summary|[5 Regression] ICE          |[5 Regression] ICE
                   |(segfault) on               |(segfault) on
                   |arm-linux-gnueabihf         |arm-linux-gnueabihf and
                   |                            |aarch64-linux-gnu
     Ever confirmed|1                           |0

--- Comment #9 from Matthias Klose <doko at gcc dot gnu.org> ---
$ g++ -c -g -O3 -fPIC track_aarch64.ii track_aarch64.ii: In member function
'void Track::prep_record_enabled(bool, void*)':
track_aarch64.ii:15:15: internal compiler error: Segmentation fault
          void Track::prep_record_enabled ( bool p1, void *) {         if (
&_route_group )     _ro
               ^
Please submit a full bug report,
with preprocessed source if appropriate.

seen on aarch64-linux-gnu too, but with a slightly different reduced test case.
r221076

(gdb) bt
#0  0x0000000000bfb5a0 in integer_zerop(tree_node const*) ()
#1  0x00000000008c1c90 in walk_ssa_copies(tree_node*, hash_set<tree_node*,
default_hashset_traits>**) ()
#2  0x00000000008c2ef4 in
ipa_polymorphic_call_context::ipa_polymorphic_call_context(tree_node*,
tree_node*, gimple_statement_base*, tree_node**) ()
#3  0x0000000000852d54 in fold_stmt_1(gimple_stmt_iterator*, bool, tree_node*
(*)(tree_node*)) ()
#4  0x0000000000a5c510 in replace_uses_by(tree_node*, tree_node*) ()
#5  0x0000000000a5cb24 in gimple_merge_blocks(basic_block_def*,
basic_block_def*) ()
#6  0x000000000073c720 in merge_blocks(basic_block_def*, basic_block_def*) ()
#7  0x0000000000a63d0c in cleanup_tree_cfg_bb(basic_block_def*) ()
#8  0x0000000000a64470 in cleanup_tree_cfg() ()
#9  0x000000000098a8dc in execute_function_todo(function*, void*) ()
#10 0x000000000098b088 in execute_todo(unsigned int) ()
#11 0x000000000098d52c in execute_one_pass(opt_pass*) ()
#12 0x000000000098d88c in execute_pass_list_1(opt_pass*) [clone .constprop.62]
()
#13 0x000000000098d8a0 in execute_pass_list_1(opt_pass*) [clone .constprop.62]
()
#14 0x000000000098d8f0 in execute_pass_list(function*, opt_pass*) ()
#15 0x000000000075eed4 in cgraph_node::expand() ()
#16 0x00000000007612f0 in symbol_table::compile() [clone .part.42] ()
#17 0x0000000000761610 in symbol_table::finalize_compilation_unit() ()
#18 0x0000000000603c0c in cp_write_global_declarations() ()
#19 0x0000000000a3020c in compile_file() ()
#20 0x0000000000595d10 in toplev::main(int, char**) ()
#21 0x00000000005965e4 in main ()


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (8 preceding siblings ...)
  2015-03-01 10:18 ` [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu doko at gcc dot gnu.org
@ 2015-03-01 10:19 ` doko at gcc dot gnu.org
  2015-03-01 15:33 ` aldyh at gcc dot gnu.org
                   ` (10 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: doko at gcc dot gnu.org @ 2015-03-01 10:19 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #10 from Matthias Klose <doko at gcc dot gnu.org> ---
Created attachment 34909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34909&action=edit
test case for aarch64


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (9 preceding siblings ...)
  2015-03-01 10:19 ` doko at gcc dot gnu.org
@ 2015-03-01 15:33 ` aldyh at gcc dot gnu.org
  2015-03-01 16:56 ` aldyh at gcc dot gnu.org
                   ` (9 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: aldyh at gcc dot gnu.org @ 2015-03-01 15:33 UTC (permalink / raw)
  To: gcc-bugs

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|2015-02-27 00:00:00         |2015-03-01
     Ever confirmed|0                           |1

--- Comment #11 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Confirmed.  Finally!  I can reproduce on a cross to aarch64-linux-gnu with the
testcase in comment 10 (attachment 34909):

./cc1plus b.c -quiet -g -O3 -fPIC -I./

b.c: In member function ‘void Track::prep_record_enabled(bool, void*)’:
b.c:15:15: internal compiler error: Segmentation fault
          void Track::prep_record_enabled ( bool p1, void *) {         if (
&_route_group )     _route_group.apply ( &Track::prep_record_enabled, p1,
&_route_group );       }
               ^
0xeecd8e crash_signal
        /source/gcc-pristine/gcc/toplev.c:383
0x11f5ec5 tree_nop_conversion
        /source/gcc-pristine/gcc/tree.c:11792
0x11f615f tree_strip_nop_conversions(tree_node*)
        /source/gcc-pristine/gcc/tree.c:11831
0x11d2b73 integer_zerop(tree_node const*)
        /source/gcc-pristine/gcc/tree.c:2218
0xcb180b walk_ssa_copies
etc
etc
>From gcc-bugs-return-478880-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Mar 01 16:20:24 2015
Return-Path: <gcc-bugs-return-478880-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 109838 invoked by alias); 1 Mar 2015 16:20:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 109781 invoked by uid 48); 1 Mar 2015 16:20:20 -0000
From: "e29253 at jp dot ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/63731] Fallback to netgo does not work
Date: Sun, 01 Mar 2015 16:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: e29253 at jp dot ibm.com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63731-4-xk8UL70TUT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63731-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63731-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg00024.txt.bz2
Content-length: 248

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc731

--- Comment #27 from Tatsushi Inagaki <e29253 at jp dot ibm.com> ---
(In reply to Ian Lance Taylor from comment #26)
> Tatsushi: are you asking about gccgo, or about gc?

I'm asking about gccgo.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (10 preceding siblings ...)
  2015-03-01 15:33 ` aldyh at gcc dot gnu.org
@ 2015-03-01 16:56 ` aldyh at gcc dot gnu.org
  2015-03-02  4:38 ` law at redhat dot com
                   ` (8 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: aldyh at gcc dot gnu.org @ 2015-03-01 16:56 UTC (permalink / raw)
  To: gcc-bugs

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

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

--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Though I think the problem is in ipa-polymorphic-call.c, the problem started
with r220743:

commit 849b1089b935f6875fe20b13f472ca955edc8223
Author: law <law@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Mon Feb 16 20:56:55 2015 +0000

        PR tree-optimization/64823
        * tree-vrp.c (identify_jump_threads): Handle blocks with no real
        statements.
        * tree-ssa-threadedge.c (potentially_threadable_block): Allow
        threading through blocks with PHIs, but no statements.
        (thread_through_normal_block): Distinguish between blocks where
        we did not process all the statements and blocks with no statements.

        PR tree-optimization/64823
        * gcc.dg/uninit-20.c: New test.

What's happening here is that the ipa_polymorphic_call_context constructor is
calling walk_ssa_copies on a PHI node that has no arguments .  This happens
because finalize_jump_threads eventually removes some PHI arguments as it's
redirecting some edges, leaving a PHI with no arguments:

SR.33_23 = PHI <>

Presumably this will get cleaned up later, but the IPA polymorphic code gets
called *while* cleaning up the CFG, and the polymorphic code (walk_ssa_copies)
cannot handle an empty PHI, which IMO it should, since it is being called from
the cleanup code after all.

Just a shot in the dark, but perhaps we want this untested patch (which fixes
the ICE)?

diff --git a/gcc/ipa-polymorphic-call.c b/gcc/ipa-polymorphic-call.c
index aaa549e..13cc7f6 100644
--- a/gcc/ipa-polymorphic-call.c
+++ b/gcc/ipa-polymorphic-call.c
@@ -835,7 +835,10 @@ walk_ssa_copies (tree op, hash_set<tree> **global_visited
= NULL)
        {
          gimple phi = SSA_NAME_DEF_STMT (op);

-         if (gimple_phi_num_args (phi) > 2)
+         if (gimple_phi_num_args (phi) > 2
+             /* We can be called while cleaning up the CFG and can
+                have empty PHIs about to be removed.  */
+             || gimple_phi_num_args (phi) == 0)
            goto done;
          if (gimple_phi_num_args (phi) == 1)
            op = gimple_phi_arg_def (phi, 0);


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (11 preceding siblings ...)
  2015-03-01 16:56 ` aldyh at gcc dot gnu.org
@ 2015-03-02  4:38 ` law at redhat dot com
  2015-03-02  5:22 ` [Bug middle-end/65233] " aldyh at gcc dot gnu.org
                   ` (7 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: law at redhat dot com @ 2015-03-02  4:38 UTC (permalink / raw)
  To: gcc-bugs

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #14 from Jeffrey A. Law <law at redhat dot com> ---
Presumably this is a case where a block has become unreachable?  Or is it a
case where the block previously had multiple preds, then by way of jump
threading we've got just a single pred and ultimately we try to merge it with
its single predecessor?

In the former case, I'd expect cleanup_tree_cfg_noloop (called from
cleanup_tree_cfg) to have removed the unreachable block(s).

Just to be clear, I'm not saying the patch is wrong, I'm just trying to
understand the events that led to a PHI with no args and whether or not it
should have already been cleaned up.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (12 preceding siblings ...)
  2015-03-02  4:38 ` law at redhat dot com
@ 2015-03-02  5:22 ` aldyh at gcc dot gnu.org
  2015-03-02  5:38 ` aldyh at gcc dot gnu.org
                   ` (6 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: aldyh at gcc dot gnu.org @ 2015-03-02  5:22 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #15 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Author: aldyh
Date: Mon Mar  2 05:22:03 2015
New Revision: 221097

URL: https://gcc.gnu.org/viewcvs?rev=221097&root=gcc&view=rev
Log:
    PR middle-end/65233
    * ipa-polymorphic-call.c (walk_ssa_copies): Handle empty PHIs.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-polymorphic-call.c


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (13 preceding siblings ...)
  2015-03-02  5:22 ` [Bug middle-end/65233] " aldyh at gcc dot gnu.org
@ 2015-03-02  5:38 ` aldyh at gcc dot gnu.org
  2015-03-02  5:49 ` aldyh at gcc dot gnu.org
                   ` (5 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: aldyh at gcc dot gnu.org @ 2015-03-02  5:38 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #14)
> Presumably this is a case where a block has become unreachable?  Or is it a
> case where the block previously had multiple preds, then by way of jump
> threading we've got just a single pred and ultimately we try to merge it
> with its single predecessor?
> 
> In the former case, I'd expect cleanup_tree_cfg_noloop (called from
> cleanup_tree_cfg) to have removed the unreachable block(s).
> 
> Just to be clear, I'm not saying the patch is wrong, I'm just trying to
> understand the events that led to a PHI with no args and whether or not it
> should have already been cleaned up.

That's the thing, walk_ssa_copies which is the one ICEing, is getting called
_while_ doing the cleanup.  So yeah, cleanup_tree_cfg_noloop is supposed to
clean this up, but that's exactly where we're ICEing ;-).

See the backtrace

#0  0x00000000011f6101 in tree_nop_conversion (exp=0xafafafafafafafaf)
    at /source/gcc/gcc/tree.c:11792
#1  0x00000000011f639c in tree_strip_nop_conversions (
    exp=<error reading variable: Cannot access memory at address
0xafafafafafafafaf>) at /source/gcc/gcc/tree.c:11831
#2  0x00000000011d2db0 in integer_zerop (expr=0xafafafafafafafaf)
    at /source/gcc/gcc/tree.c:2218
#3  0x0000000000cb1d12 in walk_ssa_copies (op=<ssa_name 0x7ffff008be58>, 
    global_visited=0x7fffffffd828)
    at /source/gcc/gcc/ipa-polymorphic-call.c:848
#4  0x0000000000cb1fed in
ipa_polymorphic_call_context::ipa_polymorphic_call_context
(this=0x7fffffffd8b0, 
    fndecl=<function_decl 0x7fffeffe9500 prep_record_enabled>, 
    ref=<obj_type_ref 0x7ffff0088780>, stmt=<gimple_call 0x7ffff008fd80>, 
    instance=0x0) at /source/gcc/gcc/ipa-polymorphic-call.c:909
#5  0x0000000000bbf216 in possible_polymorphic_call_targets (
    ref=<obj_type_ref 0x7ffff0088780>, call=<gimple_call 0x7ffff008fd80>, 
    completep=0x7fffffffd91f, cache_token=0x0)
    at /source/gcc/gcc/ipa-utils.h:120
#6  0x0000000000bb4bf9 in gimple_fold_call (gsi=0x7fffffffdc10, inplace=false)
    at /source/gcc/gcc/gimple-fold.c:3094
#7  0x0000000000bb709c in fold_stmt_1 (gsi=0x7fffffffdc10, inplace=false, 
    valueize=0xbb7672 <no_follow_ssa_edges(tree_node*)>)
    at /source/gcc/gcc/gimple-fold.c:3676
#8  0x0000000000bb76ec in fold_stmt (gsi=0x7fffffffdc10)
    at /source/gcc/gcc/gimple-fold.c:3804
#9  0x0000000000f2bce9 in replace_uses_by (name=<ssa_name 0x7ffff0092f78>, 
    val=<ssa_name 0x7ffff008be58>) at /source/gcc/gcc/tree-cfg.c:1836
#10 0x0000000000f2c164 in gimple_merge_blocks (
    a=<basic_block 0x7ffff00a2e38 (47)>, b=<basic_block 0x7ffff0086a28 (13)>)
    at /source/gcc/gcc/tree-cfg.c:1922
#11 0x00000000009f5310 in merge_blocks (a=<basic_block 0x7ffff00a2e38 (47)>, 
    b=<basic_block 0x7ffff0086a28 (13)>) at /source/gcc/gcc/cfghooks.c:769
#12 0x0000000000f43fdb in cleanup_tree_cfg_bb (
    bb=<basic_block 0x7ffff00a2e38 (47)>)
    at /source/gcc/gcc/tree-cfgcleanup.c:675
#13 0x0000000000f4405a in cleanup_tree_cfg_1 ()
    at /source/gcc/gcc/tree-cfgcleanup.c:707
#14 0x0000000000f441b6 in cleanup_tree_cfg_noloop ()
    at /source/gcc/gcc/tree-cfgcleanup.c:765
#15 0x0000000000f442c2 in cleanup_tree_cfg ()
etc
etc


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (14 preceding siblings ...)
  2015-03-02  5:38 ` aldyh at gcc dot gnu.org
@ 2015-03-02  5:49 ` aldyh at gcc dot gnu.org
  2015-03-02  5:50 ` aldyh at gcc dot gnu.org
                   ` (4 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: aldyh at gcc dot gnu.org @ 2015-03-02  5:49 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #17 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
FWIW, the removal happens by virtue of:

  /* The hash table traversals above created the duplicate blocks (and the
     statements within the duplicate blocks).  This loop creates PHI nodes for
     the duplicated blocks and redirects the incoming edges into BB to reach
     the duplicates of BB.  */
  redirection_data->traverse <ssa_local_info_t *, ssa_redirect_edges>
                (&local_info);

and right after the PHI is getting cleared, the BB has:

<bb 48>:
 pred:      
# .MEM_34 = PHI <>
# SR.33_45 = PHI <>
# SR.32_86 = PHI <>
# DEBUG this => D#8
goto <bb 47>;
 succ:       47 [69.8%]  (FALLTHRU,EXECUTABLE)

Notice the empty `pred', which would indicate to me a block that is
unreachable.

Looking at the tree dump for the rest of the function
(Track::prep_record_enabled(bool, void*)), I see no branches or fall-thrus to
BB 48, so yes... it has become unreachable and should be cleaned up, but the
ICEing code is the one that can't handle empty PHI.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (15 preceding siblings ...)
  2015-03-02  5:49 ` aldyh at gcc dot gnu.org
@ 2015-03-02  5:50 ` aldyh at gcc dot gnu.org
  2015-03-02 21:41 ` law at redhat dot com
                   ` (3 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: aldyh at gcc dot gnu.org @ 2015-03-02  5:50 UTC (permalink / raw)
  To: gcc-bugs

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

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

--- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Fixed on mainline.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (16 preceding siblings ...)
  2015-03-02  5:50 ` aldyh at gcc dot gnu.org
@ 2015-03-02 21:41 ` law at redhat dot com
  2015-03-03 19:33 ` aldyh at gcc dot gnu.org
                   ` (2 subsequent siblings)
  20 siblings, 0 replies; 22+ messages in thread
From: law at redhat dot com @ 2015-03-02 21:41 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #19 from Jeffrey A. Law <law at redhat dot com> ---
Right.  That's the last step for updating the CFG for a series of jump threads.

It's certainly the case that the redirections can leave unreachable blocks. 
But the first thing that the cfg cleanup routines ought to be doing is removing
those unreachable blocks -- before we call any of the block merging code.

That happens in cleanup_tree_cfg_noloop.  So I'd be real interested to know if
we have any unreachable blocks in the CFG after cleanup_tree_cfg_noloop has
completed.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (17 preceding siblings ...)
  2015-03-02 21:41 ` law at redhat dot com
@ 2015-03-03 19:33 ` aldyh at gcc dot gnu.org
  2015-03-04 13:27 ` rguenth at gcc dot gnu.org
  2015-03-05  8:38 ` rguenth at gcc dot gnu.org
  20 siblings, 0 replies; 22+ messages in thread
From: aldyh at gcc dot gnu.org @ 2015-03-03 19:33 UTC (permalink / raw)
  To: gcc-bugs

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard.guenther at gmail dot com

--- Comment #20 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #19)
> Right.  That's the last step for updating the CFG for a series of jump
> threads.
> 
> It's certainly the case that the redirections can leave unreachable blocks. 
> But the first thing that the cfg cleanup routines ought to be doing is
> removing those unreachable blocks -- before we call any of the block merging
> code.
> 
> That happens in cleanup_tree_cfg_noloop.  So I'd be real interested to know
> if we have any unreachable blocks in the CFG after cleanup_tree_cfg_noloop
> has completed.

I see.

Then, something's definitely odd here.

The PHI which ended up empty is SR.33_23:

  <bb 30>:
  # SR.33_23 = PHI <>
  # SR.32_80 = PHI <>
  # DEBUG this => D#8
  goto <bb 12>;

This entire block got wiped by delete_unreachable_blocks (correctly) through
cleanup_tree_cfg_noloop.

However, we still have references to
SR.33_23, which is no longer being set because BB 30 no longer exists:

  <bb 13>:
  # SR.33_83 = PHI <SR.33_23(47)>
  # SR.32_16 = PHI <SR.32_80(47)>
  # DEBUG this => &D.3962
  # DEBUG D#1 => &D.3962.pn
  # DEBUG this => D#1
  # DEBUG this => SR.33_83
  _18 = SR.33_83->_vptr.C;
  _19 = *_18;
  OBJ_TYPE_REF(_19;(struct C)SR.33_23->0) (SR.33_23);
  goto <bb 15>;

We get the ICE because, while we are analyzing OBJ_TYPE_REF() above,
we try to analyze the SR.33_23, which still points to the now defunct
PHI.

Although, if I understand Richi correctly here:

https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00038.html

...ipa_polymorphic_call_context::ipa_polymorphic_call_context() should
not be calling walk_ssa_copies() at all when called through
fold_stmt() which is certainly the case here.  Apparently,
fold_stmt() and its derivatives should not walk the SSA usa-def chain.
Is this what you meant Richi?  (BTW, where is this restriction on
fold_stmt() documented?)

If that's the case, I may have to put this PR back for Honza to
tackle/redesign.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (18 preceding siblings ...)
  2015-03-03 19:33 ` aldyh at gcc dot gnu.org
@ 2015-03-04 13:27 ` rguenth at gcc dot gnu.org
  2015-03-05  8:38 ` rguenth at gcc dot gnu.org
  20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-03-04 13:27 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 34950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34950&action=edit
CFG debugging

Just FYI - this is a local CFG debugging patch I use.  Just do

(gdb) p debug_dot_cfg (cfun)

from anywhere you like and get 'dot -Tx11' of the CFG spawned in the background
(you can continue debugging).


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [Bug middle-end/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu
  2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
                   ` (19 preceding siblings ...)
  2015-03-04 13:27 ` rguenth at gcc dot gnu.org
@ 2015-03-05  8:38 ` rguenth at gcc dot gnu.org
  20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-03-05  8:38 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Mar  5 08:37:40 2015
New Revision: 221203

URL: https://gcc.gnu.org/viewcvs?rev=221203&root=gcc&view=rev
Log:
2015-03-05  Richard Biener  <rguenther@suse.de>

    PR middle-end/65233
    * ipa-polymorphic-call.c: Include tree-ssa-operands.h and
    tree-into-ssa.h.
    (walk_ssa_copies): Revert last chage.  Instead do not walk
    SSA names registered for SSA update.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-polymorphic-call.c


^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2015-03-05  8:38 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-27 10:21 [Bug target/65233] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
2015-02-27 10:32 ` [Bug target/65233] " rguenth at gcc dot gnu.org
2015-02-27 10:41 ` ktkachov at gcc dot gnu.org
2015-02-27 10:53 ` doko at gcc dot gnu.org
2015-02-27 11:46 ` jakub at gcc dot gnu.org
2015-02-27 12:05 ` doko at gcc dot gnu.org
2015-02-27 12:07 ` jakub at gcc dot gnu.org
2015-02-27 20:31 ` aldyh at gcc dot gnu.org
2015-03-01  8:59 ` doko at gcc dot gnu.org
2015-03-01 10:18 ` [Bug target/65233] [5 Regression] ICE (segfault) on arm-linux-gnueabihf and aarch64-linux-gnu doko at gcc dot gnu.org
2015-03-01 10:19 ` doko at gcc dot gnu.org
2015-03-01 15:33 ` aldyh at gcc dot gnu.org
2015-03-01 16:56 ` aldyh at gcc dot gnu.org
2015-03-02  4:38 ` law at redhat dot com
2015-03-02  5:22 ` [Bug middle-end/65233] " aldyh at gcc dot gnu.org
2015-03-02  5:38 ` aldyh at gcc dot gnu.org
2015-03-02  5:49 ` aldyh at gcc dot gnu.org
2015-03-02  5:50 ` aldyh at gcc dot gnu.org
2015-03-02 21:41 ` law at redhat dot com
2015-03-03 19:33 ` aldyh at gcc dot gnu.org
2015-03-04 13:27 ` rguenth at gcc dot gnu.org
2015-03-05  8:38 ` rguenth at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).