public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE
Date: Mon, 03 Mar 2014 16:12:00 -0000	[thread overview]
Message-ID: <bug-58595-4-feLKTuOaaB@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-58595-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Meador Inge from comment #5)
> Created attachment 32253 [details]
> Work in progress patch.
> 
> Yeah, I am came to the same conclusion after making that comment that
> removing the asserts is a bogus approach.
> 
> Although, my follow up approach is a little different.  I was trying to
> replicate what we currently have in the 'movsi' pattern (see attached). 
> This seems to work for the basic tests I have tried.  This patch is lightly
> tested, is obviously in need of cleanup (since it duplicates code), and
> doesn't cover the thumb case.  I am just posting it for discussion purposes.
> 
> Are we guaranteed to always have the const plus form?  Or do we need to be
> more general like in the patch I attached?

It is good enough for i?86/x86_64, so I don't see why it wouldn't be for arm.
Note, this is about what the middle-end is prepared to feed to emit_move_insn,
I can't imagine it would feed something more complex than that.

rs6000 has code similar to your case and has the assert in there too.

Another alternative would be to have something like your patch, but do the
check before the
if (!TARGET_ARM)
case in arm_legitimize_address and drop the TLS handling in
thumb_legitimize_address to avoid the duplication.  I wonder how it can work on
thumb2 anyway without legitimizing TLS.
BTW, the force_operand is perhaps unnecessary, but perhaps we should recurse
into arm_legitimize_address instead, so that it takes care of out of range
addends?


  parent reply	other threads:[~2014-03-03 16:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-02 19:12 [Bug target/58595] New: " yannick.brosseau at gmail dot com
2013-10-31  9:49 ` [Bug target/58595] " ramana at gcc dot gnu.org
2013-10-31 10:00 ` ramana at gcc dot gnu.org
2014-02-21 19:13 ` meadori at codesourcery dot com
2014-02-21 19:16 ` meadori at codesourcery dot com
2014-03-03 13:40 ` jakub at gcc dot gnu.org
2014-03-03 15:47 ` meadori at codesourcery dot com
2014-03-03 16:00 ` jakub at gcc dot gnu.org
2014-03-03 16:12 ` jakub at gcc dot gnu.org [this message]
2014-03-03 16:54 ` jakub at gcc dot gnu.org
2014-03-03 17:16 ` ktkachov at gcc dot gnu.org
2014-03-04 10:15 ` ktkachov at gcc dot gnu.org
2014-03-04 13:13 ` jakub at gcc dot gnu.org
2014-03-05  8:59 ` ktkachov at gcc dot gnu.org
2014-03-06 12:07 ` jakub at gcc dot gnu.org
2014-04-10  7:46 ` jakub at gcc dot gnu.org
2014-04-10  8:03 ` jakub at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-58595-4-feLKTuOaaB@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).