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: Offloading compilers' support libraries (was: nvptx offloading patches [3/n], RFD)
Date: Thu, 19 Feb 2015 12:02:00 -0000	[thread overview]
Message-ID: <8761aydt4y.fsf@schwinge.name> (raw)
In-Reply-To: <54E5ACCE.7080502@codesourcery.com>

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

Hi!

On Thu, 19 Feb 2015 10:28:46 +0100, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 02/17/2015 05:40 PM, Jakub Jelinek wrote:
> > On Tue, Feb 17, 2015 at 04:21:06PM +0000, Joseph Myers wrote:
> >> On Tue, 17 Feb 2015, Jakub Jelinek wrote:
> >>
> >>> Third attempt failed with:
> >>> ../../../libgcc/config/nvptx/realloc.c:24:20: fatal error: stdlib.h: No such file or directory
> >>> compilation terminated.
> >>> ../../../libgcc/static-object.mk:17: recipe for target 'realloc.o' failed
> >>> make[2]: *** [realloc.o] Error 1
> >>> make[2]: *** Waiting for unfinished jobs....
> >>> make[2]: Leaving directory '/usr/src/gcc/objnvptx/nvptx-none/libgcc'
> >>> I have nvptx-newlib symlinked into the gcc tree as newlib, so I expected it
> >>> would be built in-tree, is that not the case (at least wiki/Offloading
> >>> mentions that).  Or is it just that libgcc can't really have dependencies on
> >>> newlib headers as newlib is built after libgcc?
> >>
> >> I've committed this patch to fix this last issue (the header dependence,
> >> that is; I don't know about the in-tree build).
> >
> > Thanks, sure, libgcc now builds fine, the in-tree build fails:
> > configure:4261: checking for C compiler default output file name
> > configure:4283: /usr/src/gcc/objnvptx/./gcc/xgcc -B/usr/src/gcc/objnvptx/./gcc/ -nostdinc -B/usr/src/gcc/objnvptx/nvptx-none/newlib/ -isystem /usr/src/gcc/objnvptx/nvptx-none/newlib/targ-include -isystem /usr/src/gcc/newlib/libc/include -B/usr/local/nvptx-none/bin/ -B/usr/local/nvptx-none/lib/ -isystem /usr/local/nvptx-none/include -isystem /usr/local/nvptx-none/sys-include    -g -O2   conftest.c  >&5
> > error opening libc.a
> > collect2: error: ld returned 1 exit status
> > very early during in-tree newlib configure.
> 
> Not a fix for your problem, but there's a similar issue when trying to 
> get at the libgcc for the nvptx accel compiler after it's been 
> installed. The libgcc Makefile puts it in the wrong place - 
> gcc/nvptx-none/accel/nvptx-none instead of gcc/host/accel/nvptx-none. 

I also wondered about this; it's somewhere on my TODO list...

> The patch below corrects that and removes an intelmicemul special case 
> which I believe has the same effect - Ilya, could you test this?

This code has originally been posted in
<http://news.gmane.org/find-root.php?message_id=%3C20140926123551.GA6892%40msticlxl57.ims.intel.com%3E>.

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?)

One step back -- I understand correctly that this change is to make sure
that the regular target compiler and the offloading compilers don't clash
in their installed files' names?  (By putting them into the
accel/[offloading architecture]/ subdirectory?)  (As I've written in
<http://news.gmane.org/find-root.php?message_id=%3C87vbize7zi.fsf%40schwinge.name%3E>,
I currently install into separate prefixes/DESTDIRS, because I have not
yet verified that there is no overlap in the installed files.)

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?

> Index: libgcc/Makefile.in
> ===================================================================
> --- libgcc/Makefile.in	(revision 445788)
> +++ libgcc/Makefile.in	(working copy)
> @@ -45,6 +45,7 @@ fixed_point = @fixed_point@
>  with_aix_soname = @with_aix_soname@
>  
>  host_noncanonical = @host_noncanonical@
> +real_host_noncanonical = @real_host_noncanonical@
>  target_noncanonical = @target_noncanonical@
>  
>  # List of extra object files that should be compiled for this target machine.
> @@ -185,7 +186,7 @@ STRIP = @STRIP@
>  STRIP_FOR_TARGET = $(STRIP)
>  
>  # Directory in which the compiler finds libraries etc.
> -libsubdir = $(libdir)/gcc/$(host_noncanonical)/$(version)@accel_dir_suffix@
> +libsubdir = $(libdir)/gcc/$(real_host_noncanonical)/$(version)@accel_dir_suffix@
>  # Used to install the shared libgcc.
>  slibdir = @slibdir@
>  # Maybe used for DLLs on Windows targets.
> Index: libgcc/configure.ac
> ===================================================================
> --- libgcc/configure.ac	(revision 445788)
> +++ libgcc/configure.ac	(working copy)
> @@ -398,16 +398,14 @@ esac
>  
>  # Used for constructing correct paths for offload compilers.
>  accel_dir_suffix=
> +real_host_noncanonical=${host_noncanonical}
> +echo "eaaf: $enable_as_accelerator_for"
>  if test x"$enable_as_accelerator_for" != x; then
>    accel_dir_suffix=/accel/${target_noncanonical}
> -  case "${target_noncanonical}" in
> -    *-intelmicemul-*)
> -      # In this case we expect offload compiler to be built as native, so we
> -      # need to change install directory for driver to be able to find libgcc.
> -      host_noncanonical=${enable_as_accelerator_for} ;;
> -  esac
> +  real_host_noncanonical=${enable_as_accelerator_for}
>  fi
>  AC_SUBST(accel_dir_suffix)
> +AC_SUBST(real_host_noncanonical)
>  
>  if test x"$enable_offload_targets" != x; then
>    extra_parts="${extra_parts} crtoffloadbegin.o crtoffloadend.o"


Grüße,
 Thomas

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

  reply	other threads:[~2015-02-19 11:43 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                 ` Thomas Schwinge [this message]
2015-02-19 12:11                   ` Offloading compilers' support libraries Bernd Schmidt
2015-02-19 12:19                     ` Thomas Schwinge
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=8761aydt4y.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).