[Bug target/61336] ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454

[Bug target/61336] ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu.org,
                   |                            |ubizjak at gmail dot com

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
The problem here is, that some inline asm tries to print the symbol name using
"offsetable" memory constraint. This generates:

(gdb) p debug_rtx (insn)
(insn:TI 58 57 59 (asm_operands/v ("990: nop
.pushsection .note.stapsdt,"?","note"
.balign 4
.4byte 992f-991f,994f-993f,3
991: .asciz "stapsdt"
992: .balign 4
993: .8byte 990b
.8byte _.stapsdt.base
.8byte 0
.asciz "libc"
.asciz "memory_mallopt_mxfast"
.asciz "%n0@%1 %n2@%3"
994: .balign 4
.popsection
") ("") 0 [
            (const_int 4 [0x4])
            (reg:SI 11 $11 [orig:103 value ] [103])
            (const_int -8 [0xfffffffffffffff8])
            (mem/c:DI (symbol_ref:DI ("global_max_fast") [flags 0x6] <var_decl
0x20000eaf430 global_max_fast>) [5 global_max_fast+0 S8 A64])
        ]
         [
            (asm_input:SI ("n") malloc.c:4764)
            (asm_input:SI ("nor") malloc.c:4764)
            (asm_input:SI ("n") malloc.c:4764)
            (asm_input:DI ("nor") malloc.c:4764)
        ]
         [] malloc.c:4764) malloc.c:4764 -1
     (nil))
$15 = void

which in fact contains invalid unsplit symbol reference to "global_max_fast".

So, we can either allow unsplit symbol references using following patch:

--cut here--
Index: alpha.c
===================================================================
--- alpha.c     (revision 210950)
+++ alpha.c     (working copy)
@@ -5450,7 +5450,6 @@ print_operand_address (FILE *file, rtx addr)
       offset = INTVAL (addr);
       break;

-#if TARGET_ABI_OPEN_VMS
     case SYMBOL_REF:
       fprintf (file, "%s", XSTR (addr, 0));
       return;
@@ -5463,7 +5462,6 @@ print_operand_address (FILE *file, rtx addr)
               INTVAL (XEXP (XEXP (addr, 0), 1)));
       return;

-#endif
     default:
       gcc_unreachable ();
     }
--cut here--

or your souce should be fixed to avoid memory operands in inline asm.
>From gcc-bugs-return-452741-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 28 17:15:32 2014
Return-Path: <gcc-bugs-return-452741-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31005 invoked by alias); 28 May 2014 17:15:32 -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 30951 invoked by uid 48); 28 May 2014 17:15:24 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57543] decltype needs explicit 'this' pointer in member function declaration of template class with trailing return type
Date: Wed, 28 May 2014 17:15: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.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: paolo.carlini at oracle dot com
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-57543-4-RCx5tnGnLN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57543-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57543-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-05/txt/msg02433.txt.bz2
Content-length: 490

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |paolo.carlini at oracle dot com

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Looking a bit more into it.

[Bug target/61336] ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454

[mcree at orcon dot net.nz]

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

--- Comment #2 from Michael Cree <mcree at orcon dot net.nz> ---
OK, I had reported the ICE on the basis that any ICE, whether the code under
compilation is correct or not, is a bug.

I guess you are implying that when the problem is an inlined asm then it cannot
be guaranteed that all the compiler's assumptions are satisfied thus an ICE
might be a reasonable outcome?

I think I said the source file is from glibc, but actually it is Debian eglibc,
which has come via the eglibc project from glibc before being masssaged by
Debian.  I shall try to see if I can trip the ICE on glibc source itself (it
doesn't happen with default configure options, but that's not a sufficient
test).

Is there some way one can identify in the source exactly the problematic inline
asm?  I see line 4764 of malloc.c reported in the comment above but that line
involves macros.  (The difference between the eglibc I used and glibc is not at
that point in malloc.c; it might be somewhere in the header files and the
macros defined.)

[Bug target/61336] ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson <rth at gcc dot gnu.org> ---
You're absolutely right it shouldn't ICE.  The proper solution to
anything we can't handle here should result in a call to 
output_operand_lossage, which produces a graceful error when applied
to an asm.

As for whether that symbol should have been split, or whether we should
just go ahead and allow this case for asms...  I don't currently have a
good answer.  I'll try to have a closer look soon.

[Bug target/61336] ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-06-02
           Assignee|unassigned at gcc dot gnu.org      |rth at gcc dot gnu.org
     Ever confirmed|0                           |1

[Bug target/61336] ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454

[rth at gcc dot gnu.org]

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

--- Comment #4 from Richard Henderson <rth at gcc dot gnu.org> ---
Author: rth
Date: Mon Jun  2 16:27:41 2014
New Revision: 211139

URL: http://gcc.gnu.org/viewcvs?rev=211139&root=gcc&view=rev
Log:
PR target/61336

        * config/alpha/alpha.c (print_operand_address): Allow symbolic
        addresses inside asms.  Use output_operand_lossage instead of
        gcc_unreachable.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/alpha/alpha.c

[Bug target/61336] ICE on alpha: in print_operand_address, at config/alpha/alpha.c:5454

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

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

--- Comment #5 from Richard Henderson <rth at gcc dot gnu.org> ---
The ICE has been resolved.

Note that the asm in question comes from system tap, which has not been
ported to alpha.  So you're probably better off disabling that in your
(e)glibc build too.