public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61044] Computed goto on AVR fails to use word-addressing
Date: Fri, 23 May 2014 08:53:00 -0000	[thread overview]
Message-ID: <bug-61044-4-RMtAQ7xLgp@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-61044-4@http.gcc.gnu.org/bugzilla/>

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

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gjl at gcc dot gnu.org,
                   |                            |senthil_kumar.selvaraj@atme
                   |                            |l.com

--- Comment #2 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
I don't see any difference in generated code with that patch.

Anyway, the question is /what/ the generated code should be?

The label differences would be something like

    .word pm(.L3-.L2)

because we must not generate stubs for the offset.  pm() works under the
assumption that gas does not resolve the difference and emits relocs for it,
and that pm() accepts differences.  Currently, gas will compute the difference
and come up with somethink like pm(4) which it resolves to 4 and not as 2.

Senthil, I searched for a user level documentation of -mlink-relax but with no
avail.  Is there a special reason for why there is no documentation for that
new gas command line option?

And why is this option needed in the first place? Why not always emitting
relocs for differences of labels? It does not buy us anything if gas computes
the difference ... except for annoyance like checking for -mlink-relax during
GCC configury.

What does not work is to add offsets to stub addresses, e.g. gs(.L2)+4 will
point to the next stub (if any) and *not* to .L2 + 4.  Thus, I don't think it's
worth to fix this PR and go through all the hassle with/without linker
relaxation and cater for all situations.

Instead, we should mention in the manual that the second example for computed
goto (with label differences) is not supported for AVR.  Not to mention that
alternative #1 will yield better code because there is not need to add offsets
at run time.


  parent reply	other threads:[~2014-05-23  8:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-03 11:57 [Bug target/61044] New: " dinuxbg at gmail dot com
2014-05-03 12:06 ` [Bug target/61044] " dinuxbg at gmail dot com
2014-05-23  8:53 ` gjl at gcc dot gnu.org [this message]
2014-05-27 11:48 ` senthil_kumar.selvaraj at atmel dot com
2014-05-28  8:43 ` gjl at gcc dot gnu.org
2014-05-28  8:44 ` gjl at gcc dot gnu.org
2014-05-28  8:48 ` gjl at gcc dot gnu.org
2014-05-28  8:50 ` gjl at gcc dot gnu.org
2014-05-28  8:53 ` gjl at gcc dot gnu.org
2014-05-28 17:29 ` gjl 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-61044-4-RMtAQ7xLgp@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).