[Bug target/53854] New: ICE in find_constant_pool_ref

[Bug target/53854] New: ICE in find_constant_pool_ref

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854

             Bug #: 53854
           Summary: ICE in find_constant_pool_ref
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: jakub@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
            Target: s390x-linux


void baz (void);

void
foo (void)
{
  int i;
  double d = 2.0;
  float f = 2222.0f;
  for (i = 0; i < 10; i++)
    {
      __asm ("# %0 %1" :: "or" (d), "or" (f));
      baz ();
    }
}

ICEs with -m64 -O2 in find_constant_pool_ref, which assumes a single insn
references at most one constant pool entry.  ASM_OPERANDS can reference many
more though.  This breaks systemtap probes on s390x.

[Bug target/53854] ICE in find_constant_pool_ref

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-07-04 13:15:39 UTC ---
Created attachment 27742
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27742
gcc48-pr53854.patch

Untested fix.

[Bug target/53854] ICE in find_constant_pool_ref

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-07-04
                 CC|                            |krebbel at gcc dot gnu.org,
                   |                            |uweigand at gcc dot gnu.org
   Target Milestone|---                         |4.7.2
     Ever Confirmed|0                           |1

[Bug target/53854] ICE in find_constant_pool_ref

[uweigand at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854

--- Comment #2 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2012-07-04 17:17:22 UTC ---
The problem with this is that there was a reason why I originally supported
only a single constant pool reference per instruction: there needs to be an
upper bound on the number of bytes consumed in the text section (code +
literals) by a single insn, otherwise the "pool chunkify" mechanism doesn't
work.

As an obvious extreme example, if the asm were to refer to more than 4096 bytes
of literals, it would be impossible to refer to them all using a single literal
pool base pointer.   As another obvious extreme example, if the asm *code* were
to span more than 4096 bytes, it would be impossible to have even a single
literal in the same chunk as the asm and thus be referenced from it (using the
current chunkify algorithm).

All this is less of an issue in 64-bit code since its much easier to address
literals, but we still be should be correct for 31-bit on old machines too ...

Why do the literals end up in the pool anyway in your example, as opposed to a
register?  They did with older compilers; this seems to have changed recently
due to different IRA cost computations ...   Maybe it would be better to
prevent asm statements from generating pool references; it is likely that the
asm will expect this to happen anyway?

[Bug target/53854] ICE in find_constant_pool_ref

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
         AssignedTo|jakub at gcc dot gnu.org    |unassigned at gcc dot
                   |                            |gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-07-10 08:23:33 UTC ---
It is true that asm can occupy even zero bytes (or some bytes just in other
sections, but not in text section), so even allowing a single constant pool
reference in an inline asm might be too much (if you have thousands of such
inline asms next to each other).  No idea where would you reject the constant
pool references for the asm, inline asm can use any kind of constraints.

[Bug target/53854] ICE in find_constant_pool_ref

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.2                       |4.7.3

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-20 10:16:38 UTC ---
GCC 4.7.2 has been released.

[Bug target/53854] ICE in find_constant_pool_ref

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.3                       |4.7.4

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-11 07:59:13 UTC ---
GCC 4.7.3 is being released, adjusting target milestone.

[Bug target/53854] ICE in find_constant_pool_ref

[dan at danny dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854

--- Comment #6 from Dan Horák <dan at danny dot cz> ---
FYI the error is still present in
gcc version 4.8.0 20130412 (Red Hat 4.8.0-2) (GCC) 

Target: s390-redhat-linux
>From gcc-bugs-return-422940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu May 23 08:25:05 2013
Return-Path: <gcc-bugs-return-422940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6030 invoked by alias); 23 May 2013 08:25:05 -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 5730 invoked by uid 48); 23 May 2013 08:25:01 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/57381] [4.8/4.9 Regression] array of volatile pointers hangs gcc
Date: Thu, 23 May 2013 08:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57381-4-tHISFZNN86@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57381-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57381-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: 2013-05/txt/msg01613.txt.bz2
Content-length: 1482

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW381

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The usual &a.b.c with volatile fields do not compare equal thing ...

Value numbering l_61$0$0$0_6 stmt = l_61$0$0$0_6 = MEM[(volatile int *[5][2][2]
*)&*.LC0];
RHS MEM[(volatile int *[5][2][2] *)&*.LC0] simplified to &s.f2.f0 has constants
1
Setting value number of l_61$0$0$0_6 to &s.f2.f0 (changed)

and &s.f2.f0 never comparing equal because we unshare it in every iteration.
Which is because operand_equal_p compares the FIELD_DECLs of COMPONENT_REFs
after clearing OEP_CONSTANT_ADDRESS_OF but those have TREE_SIDE_EFFECTS set
as well and we hit

  /* If ARG0 and ARG1 are the same SAVE_EXPR, they are necessarily equal.
     We don't care about side effects in that case because the SAVE_EXPR
     takes care of that for us. In all other cases, two expressions are
     equal if they have no side effects.  If we have two identical
     expressions with side effects that should be treated the same due
     to the only side effects being identical SAVE_EXPR's, that will
     be detected in the recursive calls below.
     If we are taking an invariant address of two identical objects
     they are necessarily equal as well.  */
  if (arg0 == arg1 && ! (flags & OEP_ONLY_CONST)
      && (TREE_CODE (arg0) == SAVE_EXPR
          || (flags & OEP_CONSTANT_ADDRESS_OF)
          || (! TREE_SIDE_EFFECTS (arg0) && ! TREE_SIDE_EFFECTS (arg1))))
    return 1;

[Bug target/53854] ICE in find_constant_pool_ref

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.4                       |---

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Unsetting target milestone of open non-regression bug from version of branch
being closed.

[Bug target/53854] ICE in find_constant_pool_ref

[dan at danny dot cz]

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

--- Comment #8 from Dan Horák <dan at danny dot cz> ---
for the record - ICE still present in gcc version 4.9.1 20140813 (Red Hat
4.9.1-7) (GCC)
>From gcc-bugs-return-459298-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 26 18:13:51 2014
Return-Path: <gcc-bugs-return-459298-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29588 invoked by alias); 26 Aug 2014 18:13:50 -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 29521 invoked by uid 48); 26 Aug 2014 18:13:45 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/61558] [5 Regression] ICE: Segmentation fault
Date: Tue, 26 Aug 2014 18:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-61558-4-j2MAfqdhb3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61558-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61558-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: 2014-08/txt/msg01795.txt.bz2
Content-length: 467

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #5 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Not a dup according to Jason. Reopening.

[Bug target/53854] ICE in find_constant_pool_ref

[uweigand at gcc dot gnu.org]

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

--- Comment #9 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
I just noticed that this bug has disappeared on mainline.  Binary search showed
that this happens with rev. 211007, which checks in this patch:
https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01263.html
which originated as part of this patch:
https://gcc.gnu.org/ml/gcc-patches/2013-01/msg01234.html
which implements the -fuse-caller-save feature.

This is weird, since that feature isn't even active in this test case ...

Looking at the IRA dumps reveals the following change in cost computation (note
that r49 and r50 are the two pseudos originally holding the input to the inline
asm):

Before 211007, we have:
      Allocno a1r50 of GENERAL_REGS(15) has 1 avail. regs  13, node:  13 (confl
regs =  0-5 14-36)
      Allocno a2r49 of GENERAL_REGS(15) has 1 avail. regs  13, node:  13 (confl
regs =  0-5 14-36)

At 211007, we have instead:
      Allocno a1r50 of GENERAL_REGS(15) has 8 avail. regs  6-13, node:  6-13
(confl regs =  0-5 14-36)
      Allocno a2r49 of GENERAL_REGS(15) has 8 avail. regs  6-13, node:  6-13
(confl regs =  0-5 14-36)


So it seems that before this patch, IRA thought the only possible register to
hold these values was r13, while after the patch, r6..r12 are allowable as
well.  The former seems obviously bogus.


Looking closer at the changes introduced in 211007, it seems that there is
actually a bug in that patch, which explains the change in behavior even though
-fuse-caller-save is not actually active:

Note that in ira_tune_allocno_costs, the patch changes the code to only add the
extra penalty for IRA_HARD_REGNO_ADD_COST_MULTIPLIER if the register is
call-clobbered.  This is weird, since IRA_HARD_REGNO_ADD_COST_MULTIPLIER is not
supposed to have anything to do with calls, and doesn't before the patch.

And indeed, moving the IRA_HARD_REGNO_ADD_COST_MULTIPLIER logic outside the
outer if (ira_hard_reg_set_intersection_p) re-introduces the bug.


This made me take a closer look at the definition of
IRA_HARD_REGNO_ADD_COST_MULTIPLIER, which happens to be defined solely on s390:

/* In some case register allocation order is not enough for IRA to
   generate a good code.  The following macro (if defined) increases
   cost of REGNO for a pseudo approximately by pseudo usage frequency
   multiplied by the macro value.

   We avoid usage of BASE_REGNUM by nonzero macro value because the
   reload can decide not to use the hard register because some
   constant was forced to be in memory.  */
#define IRA_HARD_REGNO_ADD_COST_MULTIPLIER(regno)       \
  (regno == BASE_REGNUM ? 0.0 : 0.5)

Interestingly, the comment says BASE_REGNUM should be avoided, but the actual
implementation of the macro avoid *all* registers *but* BASE_REGNUM ...  This
simply seems to be a bug.

Reverting the logic in that macro leads to this IRA cost calculation:
      Allocno a1r50 of GENERAL_REGS(15) has 7 avail. regs  6-12, node:  6-12
(confl regs =  0-5 14-36)
      Allocno a2r49 of GENERAL_REGS(15) has 7 avail. regs  6-12, node:  6-12
(confl regs =  0-5 14-36)

So it avoids r13 (BASE_REGNUM), but allows r6 .. r12.  This again makes the
test case pass.


I'd suggest to fix the ira_tune_allocno_costs bug introduced by 211007, and
also fix the s390 definition of IRA_HARD_REGNO_ADD_COST_MULTIPLIER (and
probably backport the latter fix to the branches).  I'll start discussing this
on the list.

This still doesn't solve the underlying problem, but should make its appearance
again as rare as it used to be ...