public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mike Stump <mikestump@comcast.net>
To: Kyrill Tkachov <kyrylo.tkachov@arm.com>
Cc: Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	Marcus Shawcroft <Marcus.Shawcroft@arm.com>
Subject: Re: [PATCH][AArch64][tests]Skip graphite tests that don't fit -mcmodel=tiny
Date: Fri, 08 Aug 2014 17:54:00 -0000	[thread overview]
Message-ID: <975E949D-CAEF-48E8-9BCF-F95188EA7A12@comcast.net> (raw)
In-Reply-To: <53E33AE9.4050902@arm.com>

On Aug 7, 2014, at 1:38 AM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
> 
> Thanks for the detailed explanation, the linker errors I was seeing were about relocations being truncated.

Ah, those are bugs in your port!  You should be able to generate large code and then relax it into short small code.  Large code, by definition, will never run into relocs being truncated.  :-)

> I've extended your patch to catch those as well. With this the tests I was seeing FAIL now are marked UNSUPPORTED.

> How is this?

No.  :-(

Those are traditionally bugs in gcc that users want gcc to fix.  Paper overing those bugs is the wrong path forward.

So, a couple of ideas come to mind.  The best, add relation and generate large by default.  Next solution, is to have a linker script that limits memory to the size that the large reloc supports.  If it is 18 bits, then limit memory to 18 bits.  Doesn’t impact normal users as they only have 18 bits or less on their system.  Next up, add a -mcmodel=large and make it the default and have people that want small code use -mcmodel=small.  Another solution is to add a non-default -mc-model=large, and generate large code with that option, and then fix the specific test cases in the gcc test suite that fail to use that option on your target.  This is a small maintenance nightmare, but…

So, which one do you like?

The model option (I just got done doing one for mine).  I was building gcc for my target, which only the simulator can run due to memory sizes and hit the relocs don’t fit.  I fixed it by 2 lines of work, one in branch and one in call, that removed the displacement forms under large model.  Generates gross code, but I only need it for testing.  For production, we default to and use small.  The reality is that while the other instruction might theoretically hit the reloc limits, in practice they don’t.

  reply	other threads:[~2014-08-08 17:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-22 11:23 Kyrill Tkachov
2014-07-22 15:04 ` Sebastian Pop
2014-07-22 15:17   ` Kyrill Tkachov
2014-07-22 20:40 ` Mike Stump
2014-07-30 21:40   ` Mike Stump
     [not found]     ` <CAJA7tRYxZbYVzrYNzj2mQNoyx2oXOmNParie4vtuXgDrTN-wUQ@mail.gmail.com>
2014-08-01  0:00       ` Mike Stump
2014-08-07  8:38         ` Kyrill Tkachov
2014-08-08 17:54           ` Mike Stump [this message]
2014-08-11  9:06             ` Richard Earnshaw
2014-08-11 17:35               ` Mike Stump
2014-08-19 13:12                 ` Kyrill Tkachov
2014-08-19 16:30                   ` Mike Stump
2014-10-21 14:08                     ` [PATCH][dejagnu] gcc-dg-prune glitch when filtering "relocation truncation" error Jiong Wang
2014-10-21 18:14                       ` Jeff Law

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=975E949D-CAEF-48E8-9BCF-F95188EA7A12@comcast.net \
    --to=mikestump@comcast.net \
    --cc=Marcus.Shawcroft@arm.com \
    --cc=Ramana.Radhakrishnan@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kyrylo.tkachov@arm.com \
    /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).