[Bug fortran/58067] New: ICE in GFortran recog.c:2158

[Bug fortran/58067] New: ICE in GFortran recog.c:2158

[woodard at redhat dot com]

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

            Bug ID: 58067
           Summary: ICE in GFortran recog.c:2158
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: woodard at redhat dot com

Created attachment 30602
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30602&action=edit
a flattened self contained version of the NAS benchmark.

When I try to compile one of the NAS benchmark's with -fpic and -mcmodel=large
with GCC 4.8.0 up through the current trunk (20130802) I get an internal
compiler error. This looks rather similar to PR56797 but that particular bug
seems to have been only on ARM and this occurs on x86_64. So it may be that
PR56797 is more expansive than initially thought or this might be a different
bug. I can't tell.

[ben@snog BT-MZ]$ PATH=/home/ben/Work/gcc-test/bin/:$PATH gfortran -c
-save-temps -O2 -g -fopenmp -fpic -mcmodel=large bt-all.f
bt-all.f: In function ‘MAIN__._omp_fn.1’:
bt-all.f:305:0: note: non-delegitimized UNSPEC UNSPEC_PLTOFF (9) found in
variable location
        do iz = 1, proc_num_zones
 ^
bt-all.f:305:0: note: non-delegitimized UNSPEC UNSPEC_PLTOFF (9) found in
variable location
bt-all.f: In function ‘MAIN__._omp_fn.0’:
bt-all.f:449:0: error: unrecognizable insn:
  999   continue
 ^
(call_insn/u 52 51 53 2 (parallel [
            (set (reg:DI 0 ax)
                (call:DI (mem:QI (symbol_ref:DI ("__tls_get_addr")) [0 S1 A8])
                    (const_int 0 [0])))
            (unspec:DI [
                    (symbol_ref:DI ("omp_cmn2a_") [flags 0x10] <var_decl
0x7f57f37f9390 omp_cmn2a>)
                ] UNSPEC_TLS_GD)
        ]) bt-all.f:48 -1
     (expr_list:REG_EH_REGION (const_int -2147483648 [0xffffffff80000000])
        (nil))
    (nil))
bt-all.f:449:0: internal compiler error: in extract_insn, at recog.c:2158
0x922c1a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
    ../.././gcc/rtl-error.c:109
0x922c49 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
    ../.././gcc/rtl-error.c:117
0x8f966a extract_insn(rtx_def*)
    ../.././gcc/recog.c:2158
0x7bdbee instantiate_virtual_regs_in_insn
    ../.././gcc/function.c:1609
0x7bdbee instantiate_virtual_regs
    ../.././gcc/function.c:1926
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

This problem doesn't seem to occur except when you have -fpic and
-mcmodel=large. Changing the memory model to medium or small or removing the
-fpic allows the code to compile.

Attached is a flattened self contained version of the NAS benchmark my fortran
is not good enough to boil it down into a more parsimonious reproducer.
>From gcc-bugs-return-427248-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Aug 03 00:21:26 2013
Return-Path: <gcc-bugs-return-427248-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21697 invoked by alias); 3 Aug 2013 00:21:26 -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 21619 invoked by uid 48); 3 Aug 2013 00:21:23 -0000
From: "ppluzhnikov at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64
Date: Sat, 03 Aug 2013 00:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ppluzhnikov at google dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58066-4-pj2OVARH7d@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58066-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58066-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-08/txt/msg00172.txt.bz2
Content-length: 343

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

--- Comment #2 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
(In reply to Andrew Pinski from comment #1)

> Which most Linux distro default to anyways ...

Ubuntu 12.04.1 LTS doesn't.
Configuring trunk GCC on it doesn't default to GNU2 TLS either.

What is the way to turn it on?

[Bug target/58067] ICE in GFortran recog.c:2158

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
You can add -mtls-dialect=gnu2 to -fpic and -mcmodel=large.
>From gcc-bugs-return-427254-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Aug 03 07:26:52 2013
Return-Path: <gcc-bugs-return-427254-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5698 invoked by alias); 3 Aug 2013 07:26:51 -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 5611 invoked by uid 48); 3 Aug 2013 07:26:47 -0000
From: "fabien at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58047] parse error with typedef introduced from base class
Date: Sat, 03 Aug 2013 07:26: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: fabien at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: fabien at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-58047-4-TemkO49S2t@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58047-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58047-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-08/txt/msg00178.txt.bz2
Content-length: 646

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

fabien at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |fabien at gcc dot gnu.org

--- Comment #4 from fabien at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #3)
> Seems closely related to PR37140.

Can be a dup indeed, but let it open. This way, I will not forget to check this
tescase when I work on PR37140 -- which I generally don't for duplicates.

[Bug target/58067] ICE in GFortran recog.c:2158

[woodard at redhat dot com]

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

--- Comment #3 from Ben Woodard <woodard at redhat dot com> ---
(In reply to Uroš Bizjak from comment #2)
> You can add -mtls-dialect=gnu2 to -fpic and -mcmodel=large.

Though doing that prevents the ICE, the compilation spits out about 78 lines
like:

bt-all.f:453:0: note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in
variable location

Google doesn't seem to give me any idea as to if I need be concerned about that
note.
>From gcc-bugs-return-427409-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 05 23:28:54 2013
Return-Path: <gcc-bugs-return-427409-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13111 invoked by alias); 5 Aug 2013 23:28:54 -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 13019 invoked by uid 48); 5 Aug 2013 23:28:49 -0000
From: "rearnsha at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/41458] Inefficient write of 32 bit value to 16 bit volatile on ARM
Date: Mon, 05 Aug 2013 23:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.4.1
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rearnsha at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-41458-4-aaJIo4gShS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-41458-4@http.gcc.gnu.org/bugzilla/>
References: <bug-41458-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-08/txt/msg00333.txt.bz2
Content-length: 153

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

--- Comment #2 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Reconfirmed.  Still happening

[Bug target/58067] ICE in GFortran recog.c:2158

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

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

--- Comment #4 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
The note just means the debug info location expression containing this
unexpected piece of RTL can't be expressed in dwarf and will thus be dropped on
the floor, so you lose a bit of debug info, but that's all.

[Bug target/58067] ICE in GFortran recog.c:2158

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
As Andrew says, the problem with -mtls-dialect=gnu (the default) is lack of TLS
support.  The tls_get_addr calls expanded by tls_global_dynamic_64_<mode> are
not recognized by the corresponding insns because the call address operand (the
__tls_get_addr symbol_ref) doesn't pass the constant_call_address_operand
predicate, configured to always fail in the LARGE code models.  I suppose it's
not appropriate to make an exception for __tls_get_addr, and we'd instead have
to make it an indirect call after loading the address from the GOT.  We'd need
new relocations and relaxation smarts in binutils for this to work.  I guess it
makes more sense to force the GNU2 tls-dialect for LARGE code models, since
that one works, and maybe switch to it by default in other models; we've had it
for long enough already.

As for the non-delegitimized notes we get in both modes, that's fixed with
something along the lines of the following patch:

--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -13827,6 +13827,21 @@ ix86_delegitimize_address (rtx x)
         x = replace_equiv_address_nv (orig_x, x);
       return x;
     }
+      if (GET_CODE (x) == PLUS
+      && ix86_pic_register_p (XEXP (x, 0))
+      && GET_CODE (XEXP (x, 1)) == CONST
+      && GET_CODE (XEXP (XEXP (x, 1), 0)) == UNSPEC
+      /* These are used in 64-bit CM_LARGE mode.  */
+      && (XINT (XEXP (XEXP (x, 1), 0), 1) == UNSPEC_PLTOFF
+          || XINT (XEXP (XEXP (x, 1), 0), 1) == UNSPEC_GOTOFF))
+    {
+      x = simplify_gen_subreg (GET_MODE (orig_x),
+                   XVECEXP (XEXP (XEXP (x, 1), 0), 0, 0),
+                   GET_MODE (x), 0);
+      if (x == NULL_RTX)
+        return orig_x;
+      return x;
+    }
       if (GET_CODE (x) != CONST
       || GET_CODE (XEXP (x, 0)) != UNSPEC
       || (XINT (XEXP (x, 0), 1) != UNSPEC_GOTPCREL

Uros (or anyone), please take this as a starting point; it might require
support for addends, even though I haven't needed them for this one testcase. 
Or maybe we don't need them, after all.  I'm not sure, so I'll leave it for
someone else who knows better.

[Bug target/58067] ICE in GFortran recog.c:2158

[woodard at redhat dot com]

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

--- Comment #6 from Ben Woodard <woodard at redhat dot com> ---
I just rebuilt the trunk with the patch that Alexandre Oliva provided and I can
confirm that it solves the problem with notes about non-delegitimized
addresses. 

However, I haven't yet tested the DWARF to make sure that it works as expected. 

If we do make -mtls-dialect=gnu2 the default or even implied when you specify
-mcmodel=large,  won't you still need to fix the problem with the unknown
instruction just in case someone does -mtls-dialect=gnu or will you just error
out saying: "-mcmodel=large is not supported within -mtls-dialect=gnu".
Personally, I believe that erroring out that way is perfectly acceptable.

[Bug target/58067] ICE in GFortran recog.c:2158

[woodard at redhat dot com]

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

--- Comment #7 from Ben Woodard <woodard at redhat dot com> ---
Created attachment 30622
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30622&action=edit
Alexandre's patch as a file rather than as text.

[Bug target/58067] ICE in GFortran recog.c:2158

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 30646
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30646&action=edit
gnu largepic TLS

An attempt to handle -mcmodel=large -fpic TLS GD/LD in the compiler.
Seems to work for me on testcase like:
__thread int a;
static __thread int b;

int
foo ()
{
  return a++ + b++;
}

int
main ()
{
  return foo () + foo () - 2;
}

but unfortunately ld will fail if this code is being attempted to link into an
executable or PIE:
/usr/bin/ld: /tmp/ccWao1Is.o: TLS transition from R_X86_64_TLSGD to
R_X86_64_GOTTPOFF against `a' at 0x26 in section `.text' failed
/tmp/ccWao1Is.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status

[Bug target/58067] ICE in GFortran recog.c:2158

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Aug 14 09:09:58 2013
New Revision: 201720

URL: http://gcc.gnu.org/viewcvs?rev=201720&root=gcc&view=rev
Log:
    PR target/58067
    * config/i386/i386.c (ix86_delegitimize_address): For CM_MEDIUM_PIC
    and CM_LARGE_PIC ix86_cmodel fall thru into the -m32 code, handle
    there also UNSPEC_PLTOFF.

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

Author: jakub
Date: Wed Aug 14 09:29:22 2013
New Revision: 201721

URL: http://gcc.gnu.org/viewcvs?rev=201721&root=gcc&view=rev
Log:
    PR target/58067
    * config/i386/i386.c (ix86_delegitimize_address): For CM_MEDIUM_PIC
    and CM_LARGE_PIC ix86_cmodel fall thru into the -m32 code, handle
    there also UNSPEC_PLTOFF.

Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/i386/i386.c

[Bug target/58067] ICE in GFortran recog.c:2158

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Aug 28 16:31:41 2013
New Revision: 202055

URL: http://gcc.gnu.org/viewcvs?rev=202055&root=gcc&view=rev
Log:
    PR target/58067
    * config/i386/i386.md (*tls_global_dynamic_64_largepic): New insn.
    (*tls_local_dynamic_base_64_largepic): Likewise.
    (tls_global_dynamic_64_<mode>, tls_local_dynamic_base_64_<mode>):
    Remove predicate from call operand.
    * config/i386/i386.c (ix86_tls_get_addr): For -mcmodel=large -fpic
    return sum of pic_offset_table_rtx and UNSPEC_PLTOFF of the symbol.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/config/i386/i386.md

[Bug target/58067] ICE in GFortran recog.c:2158

[tejohnson at google dot com]

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

Teresa Johnson <tejohnson at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tejohnson at google dot com

--- Comment #11 from Teresa Johnson <tejohnson at google dot com> ---
Is this issue fixed on trunk? The bug is still in state UNCONFIRMED.

Just hit this on the google/4_8 branch, since the last fix (r202055) wasn't
backported to gcc-4_8. I am going to backport r202055 to google/4_8 as that
seems to fix the problem.

Google ref b/15576865.

Thanks,
Teresa

[Bug target/58067] ICE in GFortran recog.c:2158

[zsojka at seznam dot cz]

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

Zdenek Sojka <zsojka at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zsojka at seznam dot cz

--- Comment #13 from Zdenek Sojka <zsojka at seznam dot cz> ---
Even the original fortran testcase does not fail in 8.3.1, 9.3.0, 10.3.0,
11.1.0 for me.

[Bug target/58067] ICE in GFortran recog.c:2158

[pinskia at gcc dot gnu.org]

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

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 46250 has been marked as a duplicate of this bug. ***

[Bug target/58067] ICE in GFortran recog.c:2158

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.9.0

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.  There is PR 79497 for the non PIC case with global-dynamic TLS.