[Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

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

            Bug ID: 65729
           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 with r221867 on arm-linux-gnueabihf, building the cgal and k3d packages.

$ g++ -c -g -O2 boolean.ii 
boolean.ii: In function '(static initializers for boolean.ii)':
boolean.ii:18:36: internal compiler error: in prohibited_class_reg_set_mode_p,
at lra-constraints.c:1659
 void fn1() { Interval_nt<>::m_fn1; }
                                    ^
0x58af03 prohibited_class_reg_set_mode_p
        ../../src/gcc/lra-constraints.c:1659
0x58da27 process_alt_operands
        ../../src/gcc/lra-constraints.c:2345
0x58f98f curr_insn_transform
        ../../src/gcc/lra-constraints.c:3464
0x5919e3 lra_constraints(bool)
        ../../src/gcc/lra-constraints.c:4442
0x585863 lra(_IO_FILE*)
        ../../src/gcc/lra.c:2315
0x5558c7 do_reload
        ../../src/gcc/ira.c:5418
0x5558c7 execute
        ../../src/gcc/ira.c:5589
Please submit a full bug report,
with preprocessed source if appropriate.

$ cat boolean.ii
template <bool = true> class Interval_nt {
  typedef Interval_nt IA;

public:
  Interval_nt(double, double) { b; }
  static IA m_fn1() { IA(0, 0); }
  struct Test_runtime_rounding_modes {
    Test_runtime_rounding_modes() {
      double x;
      asm volatile("" : "+gw"(x));
    }
  } static b;
};

template <bool Protected>
typename Interval_nt<Protected>::Test_runtime_rounding_modes
    Interval_nt<Protected>::b;
void fn1() { Interval_nt<>::m_fn1; }

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5-20150404-0ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,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
--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=yes
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 5.0.0 20150404 (experimental) [trunk revision 221867] (Ubuntu
5-20150404-0ubuntu11)

[Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-10
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |vmakarov at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems -march=armv7-a -mfloat-abi=hard -O2 is needed to trigger it.
Reduced testcase:
double
foo (void)
{
  double x = 0.0;
  asm volatile ("" : "+gw" (x));
  return x;
}
Already ICEd back in February on the trunk (don't have older snapshots), and
4.9.0 20140401 doesn't ICE.

[Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ra
           Priority|P3                          |P1

[Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems the ICE or successful compilation aren't the only thing gcc used to
produce here:

old - r218687 ok     
r218688 - r218759 error: inconsistent operand constraints in an ‘asm’   
r218760 - r220293 ok 
r220294 - latest internal compiler error: in prohibited_class_reg_set_mode_p,
at lra-constraints.c
>From gcc-bugs-return-483260-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 10 09:04:20 2015
Return-Path: <gcc-bugs-return-483260-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 110008 invoked by alias); 10 Apr 2015 09:04:19 -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 107718 invoked by uid 48); 10 Apr 2015 09:04:15 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65727] [4.8/4.9/5 Regression] Segfault With Decltype In Lambda Expression Used To Initialize Static Class Member
Date: Fri, 10 Apr 2015 09:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: major
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.5
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65727-4-kjxR0i1rkJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65727-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65727-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-04/txt/msg00812.txt.bz2
Content-length: 1435

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Here, we're trying to build_x_indirect_ref for a NULL pointer, that is bad.
The reason is that here
 787       /* In a lambda, need to go through 'this' capture.  */
 788       tree lam = CLASSTYPE_LAMBDA_EXPR (current_class_type);
 789       tree cap = lambda_expr_this_capture (lam, add_capture_p);
 790       if (cap != error_mark_node)
 791         object = build_x_indirect_ref (EXPR_LOCATION (object), cap,
 792                                        RO_NULL, tf_warning_or_error);
lambda_expr_this_capture returns NULL: it's looking for 'this', but doesn't
find it.

The fix in r215478 [1] dealt with not finding 'this' by checking for
error_mark, but perhaps we should also check whether the capture is non-NULL:

--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -787,7 +787,7 @@ maybe_resolve_dummy (tree object, bool add_capture_p)
       /* In a lambda, need to go through 'this' capture.  */
       tree lam = CLASSTYPE_LAMBDA_EXPR (current_class_type);
       tree cap = lambda_expr_this_capture (lam, add_capture_p);
-      if (cap != error_mark_node)
+      if (cap && cap != error_mark_node)
        object = build_x_indirect_ref (EXPR_LOCATION (object), cap,
                                       RO_NULL, tf_warning_or_error);
     }

[1] https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01878.html

[Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> Seems -march=armv7-a -mfloat-abi=hard -O2 is needed to trigger it.
-mfpu=vfpv3-d16 is also needed

[Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Yvan Roux from comment #4)
> For me the assertion in prohibited_class_reg_set_mode_p is not right, it
> checks that set is a subset of reg_class_contents[rclass] and my
> understanding is that it should be the opposite:
> 
> lra_assert (hard_reg_set_subset_p (reg_class_contents[rclass],set));
> 
> With this modification the test is fixed (full validation is ongoing).
> 
> Do I miss something Vlad ?

After some investigation done, I believe you are right, Yvan. 
this_alternative_set is always not smaller than contents of this_alternative as
we use reg_class_subunion.  So you can submit your patch with swapping
arguments in the assert call, of course after testing on x86-64 at least.  I am
approving the patch.  If you don't respond it in a few hours, I'll do it
myself.  Thanks.

By the way, it is a bad practice for RA not define classes which are union of
classes can be used for the same operand.  In this case, we could use
GENERAL_REGS or VFP_LO_REGS but only VFP_LO_REGS will be used only as it is a
result of reg_class_subunion[GENERAL_REGS][VFP_LO_REGS].  But fixing it is not
a task for GCC-5.0 as we are at the very end of creation of a new release. 
Fixing RA bugs has a big chance introducing new ones until it is stabilized. 
This is a situation what we actually see now.

[Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Vladimir Makarov from comment #5)
> (In reply to Yvan Roux from comment #4)
> > For me the assertion in prohibited_class_reg_set_mode_p is not right, it
> > checks that set is a subset of reg_class_contents[rclass] and my
> > understanding is that it should be the opposite:
> > 
> > lra_assert (hard_reg_set_subset_p (reg_class_contents[rclass],set));
> > 
> > With this modification the test is fixed (full validation is ongoing).
> > 
> > Do I miss something Vlad ?
> 
> After some investigation done, I believe you are right, Yvan. 
> this_alternative_set is always not smaller than contents of this_alternative
> as we use reg_class_subunion.  So you can submit your patch with swapping
> arguments in the assert call, of course after testing on x86-64 at least.  I
> am approving the patch.  If you don't respond it in a few hours, I'll do it
> myself.  Thanks.
> 
> By the way, it is a bad practice for RA not define classes which are union
> of classes can be used for the same operand.  In this case, we could use
> GENERAL_REGS or VFP_LO_REGS but only VFP_LO_REGS will be used only as it is
> a result of reg_class_subunion[GENERAL_REGS][VFP_LO_REGS].  But fixing it is
> not a task for GCC-5.0 as we are at the very end of creation of a new
> release.  Fixing RA bugs has a big chance introducing new ones until it is
> stabilized.  This is a situation what we actually see now.

So, could we perhaps just comment out the lra_assert for GCC 5.1 release, then
when stage1 reopens test the other order and if it works everywhere, after a
few weeks backport that to the branch?  Not that it is very important, because
the release will be --enable-checking=release for most users and thus the
assert will be ignored anyway.
Just commenting out the assert means that no further testing is needed on it
right now, the patch would be obvious...

[Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[yroux at gcc dot gnu.org]

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

--- Comment #7 from Yvan Roux <yroux at gcc dot gnu.org> ---
k, my validation is ok. I'll be off during ~3h and will submit it when I'm back
(or the assertion commenting patch) if it's better for 5.1

[Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Fri Apr 10 16:05:26 2015
New Revision: 221975

URL: https://gcc.gnu.org/viewcvs?rev=221975&root=gcc&view=rev
Log:
2015-04-10  Vladimir Makarov  <vmakarov@redhat.com>

    PR target/65729
    * lra-constraints.c (prohibited_class_reg_set_mode_p): Comment the
    assert.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-constraints.c

[Bug target/65729] [5/6 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3
   Target Milestone|5.0                         |6.0
            Summary|[5 Regression] ICE (in      |[5/6 Regression] ICE (in
                   |prohibited_class_reg_set_mo |prohibited_class_reg_set_mo
                   |de_p, at lra-constraints.c) |de_p, at lra-constraints.c)
                   |on arm-linux-gnueabihf      |on arm-linux-gnueabihf

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No longer a GCC 5.1 blocker with the assert commented out.

[Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|6.0                         |5.0
            Summary|[5/6 Regression] ICE (in    |[5 Regression] ICE (in
                   |prohibited_class_reg_set_mo |prohibited_class_reg_set_mo
                   |de_p, at lra-constraints.c) |de_p, at lra-constraints.c)
                   |on arm-linux-gnueabihf      |on arm-linux-gnueabihf

--- Comment #10 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Vladimir Makarov from comment #5)
> > (In reply to Yvan Roux from comment #4)
> > > For me the assertion in prohibited_class_reg_set_mode_p is not right, it
> > > checks that set is a subset of reg_class_contents[rclass] and my
> > > understanding is that it should be the opposite:
> > > 
> > > lra_assert (hard_reg_set_subset_p (reg_class_contents[rclass],set));
> > > 
> > > With this modification the test is fixed (full validation is ongoing).
> > > 
> > > Do I miss something Vlad ?
> > 
> > After some investigation done, I believe you are right, Yvan. 
> > this_alternative_set is always not smaller than contents of this_alternative
> > as we use reg_class_subunion.  So you can submit your patch with swapping
> > arguments in the assert call, of course after testing on x86-64 at least.  I
> > am approving the patch.  If you don't respond it in a few hours, I'll do it
> > myself.  Thanks.
> > 
> > By the way, it is a bad practice for RA not define classes which are union
> > of classes can be used for the same operand.  In this case, we could use
> > GENERAL_REGS or VFP_LO_REGS but only VFP_LO_REGS will be used only as it is
> > a result of reg_class_subunion[GENERAL_REGS][VFP_LO_REGS].  But fixing it is
> > not a task for GCC-5.0 as we are at the very end of creation of a new
> > release.  Fixing RA bugs has a big chance introducing new ones until it is
> > stabilized.  This is a situation what we actually see now.
> 
> So, could we perhaps just comment out the lra_assert for GCC 5.1 release,
> then when stage1 reopens test the other order and if it works everywhere,
> after a few weeks backport that to the branch?  Not that it is very
> important, because the release will be --enable-checking=release for most
> users and thus the assert will be ignored anyway.
> Just commenting out the assert means that no further testing is needed on it
> right now, the patch would be obvious...

OK. I'll do it.  As I understand 
(In reply to Yvan Roux from comment #7)
> k, my validation is ok. I'll be off during ~3h and will submit it when I'm
> back (or the assertion commenting patch) if it's better for 5.1

I've just commented the assert.  We will fix it for 5.1.

So, Jakub, I did what you asked as it is important for your work on release
candidate.

Although I'd like to work on PR65710 but I am not sure it will be fixed soon as
it is a performance bug now and will take at least a few days to fix it.  So
the PR65710 is also work for 5.1.

[Bug target/65729] [5/6 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.0                         |6.0
            Summary|[5 Regression] ICE (in      |[5/6 Regression] ICE (in
                   |prohibited_class_reg_set_mo |prohibited_class_reg_set_mo
                   |de_p, at lra-constraints.c) |de_p, at lra-constraints.c)
                   |on arm-linux-gnueabihf      |on arm-linux-gnueabihf

[Bug target/65729] [5/6 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf

[yroux at gcc dot gnu.org]

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

Yvan Roux <yroux at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassigned at gcc dot gnu.org      |yroux at gcc dot gnu.org

--- Comment #12 from Yvan Roux <yroux at gcc dot gnu.org> ---
Now fixed.