public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: Bernd Schmidt <bernds@codesourcery.com>,
	Jakub Jelinek <jakub@redhat.com>,	Ilya Verbin <iverbin@gmail.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
	Jan Hubicka <hubicka@ucw.cz>,	<gcc-patches@gcc.gnu.org>,
	Joseph Myers <joseph@codesourcery.com>,
	<andrey.turetskiy@intel.com>, <kirill.yukhin@gmail.com>
Subject: Re: Offloading compilers' support libraries
Date: Thu, 19 Feb 2015 12:19:00 -0000	[thread overview]
Message-ID: <873862drj2.fsf@schwinge.name> (raw)
In-Reply-To: <54E5D234.9050209@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

Hi!

On Thu, 19 Feb 2015 13:08:20 +0100, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 02/19/2015 12:42 PM, Thomas Schwinge wrote:
> > This specific buglet aside (that the handling of intelmic and nvptx
> > offloading is inconsistent) -- will we have to add such handling to each
> > and every library that is built for the offloading compilers?  (Including
> > libraries that aren't part of the GCC sources, but may be built as part
> > of GCC's build process, such as when newlib is linked into [GCC]/newlib?)
> 
> No, they go into different directories. Only libgcc.a (along with a very 
> few other pieces) is installed under lib/gcc/...

Thanks, I see.

> > Then, why does this only apply to libsubdir?  What about header files,
> > documentation files, and so on?  (If they aren't expected to differ
> > between the target and offloading compilers, I think it's still not a
> > good idea to arbitrarely have them be overwritten by on respective build
> > tree's make install process.)  Should we have a more general solution to
> > this problem?
> 
> That stuff goes into the normal lib and include directories. I'm 
> guessing a sysroot is what you want to keep it separate.

My asumption is that it is always safe to install non-native (that is
cross) GCC installations into the same prefix.  (Which would resolve this
problem of clashing file names for target and offloading compilers for
good.)

So, the next question is, instead of this special handling, why can't we
require the offloading compilers to always be configured as cross
compilers?  Or, why is it a requirement that the intelmic offloading
compiler is configured as a native compiler?


Grüße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 472 bytes --]

  reply	other threads:[~2015-02-19 12:19 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-01 11:58 nvptx offloading patches [3/n], RFD Bernd Schmidt
2014-11-03 22:28 ` Jeff Law
2014-11-04 12:38   ` nvptx offloading patches [3/n], i386 bits RFD Bernd Schmidt
2014-11-04 18:58     ` Uros Bizjak
2014-11-04 21:50     ` Jeff Law
2014-11-05  0:23       ` Bernd Schmidt
2014-11-14 18:42         ` Bernd Schmidt
2015-02-04 11:38 ` nvptx offloading patches [3/n], RFD Jakub Jelinek
2015-02-09 10:20   ` Richard Biener
2015-02-16 21:08     ` Jakub Jelinek
2015-02-16 21:35       ` Richard Biener
2015-02-16 21:44         ` Jakub Jelinek
2015-02-17 10:00           ` Richard Biener
2015-02-18 10:00             ` Jakub Jelinek
2015-02-25  8:51               ` Patch ping Jakub Jelinek
2015-02-25  9:30                 ` Richard Biener
2015-02-25 16:51                   ` Jakub Jelinek
2015-02-18  9:05           ` nvptx offloading patches [3/n], RFD Thomas Schwinge
2015-02-17 13:32       ` Ilya Verbin
2015-02-17 15:39         ` Jakub Jelinek
2015-02-17 16:21           ` Joseph Myers
2015-02-17 16:40             ` Jakub Jelinek
2015-02-18  9:12               ` Thomas Schwinge
2015-02-18 10:27                 ` Jakub Jelinek
2015-02-18 11:34                 ` Jakub Jelinek
2015-02-18 12:10                   ` Thomas Schwinge
2015-02-18 12:35                     ` Jakub Jelinek
2015-02-19 10:50                       ` If we're building an offloading compiler, always enable the LTO front end (was: nvptx offloading patches [3/n], RFD) Thomas Schwinge
2015-02-19 10:53                         ` Jakub Jelinek
2015-02-20  9:42                           ` Thomas Schwinge
2015-02-19 10:20               ` nvptx offloading patches [3/n], RFD Bernd Schmidt
2015-02-19 12:02                 ` Offloading compilers' support libraries (was: nvptx offloading patches [3/n], RFD) Thomas Schwinge
2015-02-19 12:11                   ` Offloading compilers' support libraries Bernd Schmidt
2015-02-19 12:19                     ` Thomas Schwinge [this message]
2015-02-20 15:35                       ` Ilya Verbin
2015-02-20 19:59                         ` Ilya Verbin
2015-02-26 19:35                           ` Ilya Verbin
2015-02-20  9:33                 ` Offloading compilers' libgcc installation (was: nvptx offloading patches [3/n], RFD) Thomas Schwinge
2015-02-20 19:32                   ` Ilya Verbin
2015-03-10 12:35                     ` Offloading compilers' libgcc installation Thomas Schwinge
2015-04-27 16:15                       ` Thomas Schwinge
2015-04-27 16:16                         ` Jakub Jelinek

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=873862drj2.fsf@schwinge.name \
    --to=thomas@codesourcery.com \
    --cc=andrey.turetskiy@intel.com \
    --cc=bernds@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=iverbin@gmail.com \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=kirill.yukhin@gmail.com \
    --cc=richard.guenther@gmail.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).