public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "prathamesh3492 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
Date: Tue, 28 Apr 2015 22:40:00 -0000	[thread overview]
Message-ID: <bug-65837-4-YDa9VAGX7x@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-65837-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #18 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 35420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35420&action=edit
patch to override default options by options in object file

Hi,

The following untested patch gives preference to option value in object file.
In run_gcc(),
options from COLLECT_GCC_OPTIONS which are taken from command line are stored
in decoded_options.
options from object file are stored in fdecoded_options.
so override the option in decoded_options if it is present in fdecoded_options.

With the patch this works:
arm-linux-gnueabihf-gcc test.c -mfpu=neon -flto -c
arm-linux-gnueabihf-gcc test.o -flto 
only passes -mfpu=neon to lto1

However the patch doesn't work when same option is passed different values at
compile and link-time:
arm-linux-gnuebihf-gcc test.c -mfpu=neon -flto -c
arm-linux-gnueabihf-gcc test.o -mfpu=vfpv3-d16 -flto

In this case, -mfpu=neon is still passed to lto1, since the patch prefers
option value from object file.
Without the patch, the option from the command line was given preference.

for both the following cases: 
arm-linux-gnueabihf-gcc test.o -flto
arm-linux-gnueabihf-gcc test.o -flto -mfpu=vfpv3-d16

COLLECT_GCC_OPTIONS contains "-mfpu=vfpv3-d16", however in the first case it
isn't explictly passed by user, so passing -mfpu=neon
would be correct. In the second case, since -mfpu=vfpv3-d16 is passed
intentionally by user, should it be considered
as an error - "conflicting options" ?

Unfortunately, it looks like there is no way to distinguish between options
defined by default and explicitly passed options from COLLECT_GCC_OPTIONS and
that's the only way command line options are passed to lto-wrapper from the
driver. One way would be to modify COLLECT_GCC_OPTIONS in the driver to
indicate which options were explicitly passed from command line.
For instance, additionally COLLECT_GCC_OPTIONS would contain 
"-mfpu=vfpv3-d16-explicit" to indiciate that -mfpu=vfpv3-d16 was
passed from command line and not set by default. In lto-wrapper the options
could be parsed to check if they have "explicit" suffix and thus distinguish
between explicit and defualt defined options.
Does that sound reasonable ? I would be grateful for suggestions.

Thank you,
Prathamesh


  parent reply	other threads:[~2015-04-28 22:40 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-21 20:28 [Bug target/65837] New: " prathamesh3492 at gcc dot gnu.org
2015-04-22  8:54 ` [Bug target/65837] " rguenth at gcc dot gnu.org
2015-04-22 19:53 ` prathamesh3492 at gcc dot gnu.org
2015-04-22 23:38 ` prathamesh3492 at gcc dot gnu.org
2015-04-23  8:18 ` rguenth at gcc dot gnu.org
2015-04-23  8:18 ` rguenther at suse dot de
2015-04-23 11:46 ` rguenth at gcc dot gnu.org
2015-04-23 12:18 ` prathamesh3492 at gcc dot gnu.org
2015-04-23 12:20 ` rguenther at suse dot de
2015-04-23 13:17 ` ramana at gcc dot gnu.org
2015-04-23 13:50 ` prathamesh3492 at gcc dot gnu.org
2015-04-23 13:52 ` ramana at gcc dot gnu.org
2015-04-28 10:48 ` prathamesh3492 at gcc dot gnu.org
2015-04-28 14:14 ` prathamesh3492 at gcc dot gnu.org
2015-04-28 19:22 ` prathamesh3492 at gcc dot gnu.org
2015-04-28 22:40 ` prathamesh3492 at gcc dot gnu.org [this message]
2015-04-29  7:42 ` rguenther at suse dot de
2015-04-29  7:42 ` rguenth at gcc dot gnu.org
2015-04-29  8:00 ` ramana at gcc dot gnu.org
2015-04-29 11:30 ` ramana.radhakrishnan at arm dot com
2015-05-05 15:18 ` ktkachov at gcc dot gnu.org
2015-05-19 13:44 ` chrbr at gcc dot gnu.org
2015-05-19 15:49 ` ramana at gcc dot gnu.org
2015-05-20 13:21 ` chrbr at gcc dot gnu.org
2015-06-22  8:22 ` chrbr 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-65837-4-YDa9VAGX7x@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).