[Bug target/58067] ICE in GFortran recog.c:2158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #15 from Andrew Pinski --- Fixed. There is PR 79497 for the non PIC case with global-dynamic TLS.
[Bug target/58067] ICE in GFortran recog.c:2158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 --- Comment #14 from Andrew Pinski --- *** Bug 46250 has been marked as a duplicate of this bug. ***
[Bug target/58067] ICE in GFortran recog.c:2158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 Zdenek Sojka changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #13 from Zdenek Sojka --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #12 from Arseny Solokha --- At least the C testcase in comment 8 was fixed for 4.9 and subsequent releases.
[Bug target/58067] ICE in GFortran recog.c:2158
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
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=202055root=gccview=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
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=201720root=gccview=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=201721root=gccview=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
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=30646action=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
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
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
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
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=30622action=edit Alexandre's patch as a file rather than as text.
[Bug target/58067] ICE in GFortran recog.c:2158
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.
[Bug target/58067] ICE in GFortran recog.c:2158
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.
[Bug target/58067] ICE in GFortran recog.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||aarch64-linux-gnu Component|fortran |target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I don't think -mcmodel=large support has been added for TLS yet.
