Re: Issue with sub-object __builtin_object_size
Jason Merrill wrote:
> Well, __builtin_object_size seems to be pretty fragile magic. To make
> it work I guess you could add a wrapper for poll that takes a Pollfd and
> does a reinterpret_cast, i.e.
>
> inline int poll(Pollfd* p, nfds_t n, int t)
> {
>return poll(reinterpret_cast(p), n, t);
> }
>
> so that you force the conversion to ignore the inheritance relationship
> and thereby avoid the COMPONENT_REF.
That does indeed seem to work for my test case, thanks!
Given that the _FORTIFY_SOURCE documentation already states that:
With _FORTIFY_SOURCE set to 2 some more checking is added,
but some conforming programs might fail.
I guess having to use a workaround like the above is good enough.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Offloading not relocatable
Hi! So, with the patch (probably undesirable) I've posted, I've managed to configure/make/make install DESTDIR=... the offload compiler and configure/make/make install DESTDIR=... the host compiler. Generally gcc is a relocatable package, so appart from perhaps needing to add LD_LIBRARY_PATH it doesn't matter if the gcc installed tree as whole lives somewhere else than prefix (DESTDIR=/usr/src/gcc-git/objinst is what I've been using), one can still use the compiler normally. But apparently that is not the case with offloading: /usr/src/gcc-git/objinst/usr/local/bin/gcc -fopenmp -o target-1 target-1.c collect2: error trying to exec '/usr/local/bin/x86_64-intelmic-linux-gnu-g++': execvp: No such file or directory lto-wrapper: fatal error: /usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload terminated with signal 11 [Segmentation fault], core dumped compilation terminated. /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status >From -v dump, that sounds like a bug in mkoffload, which has been found properly relatively to the gcc driver or whatever. /usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload @/tmp/ccS6Q83l collect2: error trying to exec '/usr/local/bin/x86_64-intelmic-linux-gnu-g++': execvp: No such file or directory lto-wrapper: fatal error: /usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload terminated with signal 11 [Segmentation fault], core dumped compilation terminated. /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status So, I'd say that mkoffload should be using similar stuff like the gcc.c driver uses to find cc1 relative to the location of the gcc binary. Also, unrelated to that, I've mentioned to Kirill on IRC privately that it would be nice if the libgomp offloading plugin API/ABI used some clearly libgomp & offloading related prefix for all the: get_type get_num_devices offload_register device_init device_get_table device_alloc device_free device_dev2host device_host2dev device_run symbols that are part of the plugin interface (GOMP_OFFLOAD_*, or whatever else). Jakub
Re: Offloading not relocatable
On Wed, Sep 17, 2014 at 04:21:42PM +0200, Jakub Jelinek wrote:
> So, I'd say that mkoffload should be using similar stuff like the gcc.c
> driver uses to find cc1 relative to the location of the gcc binary.
E.g. strace can tell where gcc driver is looking for cc1:
mv
/usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1{,.xx}
strace -e access,stat /usr/src/gcc-git/objinst/usr/local/bin/gcc -fopenmp -o
target-1.s target-1.c -S
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc-git/objinst/usr/local/bin/", X_OK) = 0
access("/usr/src/gcc-git/objinst/usr/local/bin/", X_OK) = 0
access("target-1.c", F_OK) = 0
access("/usr/src/gcc-git/objinst/usr/local/bin/", X_OK) = 0
access("/usr/src/gcc-git/objinst/usr/local/bin/", X_OK) = 0
access("/usr/src/gcc-git/objinst/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.0.0/specs",
R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc-git/objinst/usr/local/bin/../lib/gcc/specs", R_OK) = -1
ENOENT (No such file or directory)
access("/usr/src/gcc-git/objinst/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/5.0.0/specs",
R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc-git/objinst/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/lib/specs",
R_OK) = -1 ENOENT (No such file or directory)
access("/usr/local/lib/gcc/x86_64-unknown-linux-gnu/specs", R_OK) = -1 ENOENT
(No such file or directory)
access("/usr/src/gcc-git/objinst/usr/local/bin/", X_OK) = 0
stat("/usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1",
0x7fff73be0aa0) = -1 ENOENT (No such file or directory)
stat("/usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/cc1",
0x7fff73be0aa0) = -1 ENOENT (No such file or directory)
stat("/usr/src/gcc-git/objinst/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/5.0.0/cc1",
0x7fff73be0aa0) = -1 ENOENT (No such file or directory)
stat("/usr/src/gcc-git/objinst/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/bin/cc1",
0x7fff73be0aa0) = -1 ENOENT (No such file or directory)
gcc: error trying to exec 'cc1': execvp: No such file or directory
mkoffload should make similar attempts to find the offloading compiler
driver. It should try (relative to mkoffload binary) probably:
../../../../../bin/x86_64-intelmic-linux-gnu-g++
(why does it try g++ and not gcc btw?), then perhaps:
./x86_64-intelmic-linux-gnu-g++
(so that one can e.g. put a symlink next to mkoffload and point it wherever
needed)
and perhaps as last fallback, try to execute x86_64-intelmic-linux-gnu-g++
from PATH env var.
Jakub
Re: Offloading not relocatable
On 09/17/2014 04:42 PM, Jakub Jelinek wrote: mkoffload should make similar attempts to find the offloading compiler driver. It should try (relative to mkoffload binary) probably: ../../../../../bin/x86_64-intelmic-linux-gnu-g++ (why does it try g++ and not gcc btw?), then perhaps: ./x86_64-intelmic-linux-gnu-g++ (so that one can e.g. put a symlink next to mkoffload and point it wherever needed) and perhaps as last fallback, try to execute x86_64-intelmic-linux-gnu-g++ from PATH env var. It should be easier - the nvptx mkoffload examines COLLECT_GCC for a path, and uses that if it's available (otherwise relying on PATH). I don't know what the mic offload is doing, I haven't looked yet. Bernd
Re: Offloading not relocatable
On Wed, Sep 17, 2014 at 04:21:42PM +0200, Jakub Jelinek wrote: > >From -v dump, that sounds like a bug in mkoffload, which has been found > properly relatively to the gcc driver or whatever. > > /usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload > @/tmp/ccS6Q83l > collect2: error trying to exec > '/usr/local/bin/x86_64-intelmic-linux-gnu-g++': execvp: No such file or > directory > lto-wrapper: fatal error: > /usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload > terminated with signal 11 [Segmentation fault], core dumped > compilation terminated. > /usr/bin/ld: lto-wrapper failed > collect2: error: ld returned 1 exit status > In the same setup, I've added (as root) #!/bin/sh exec /usr/src/gcc-git/objinst/usr/local/bin/x86_64-intelmic-linux-gnu-g++ "$@" script to /usr/local/bin/x86_64-intelmic-linux-gnu-g++ . But things don't work in that case either, the error is now: /usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload @/tmp/cc0nIjXd x86_64-intelmic-linux-gnu-g++: error trying to exec 'cc1plus': execvp: No such file or directory lto-wrapper: fatal error: /usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload terminated with signal 11 [Segmentation fault], core dumped compilation terminated. /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status which presumably means that some undesirable vars from host environment were kept by mkoffload in the environment for the offloading compiler and that has the undesirable effect of affecting how the offloading compiler driver works. Because, if I invoke /usr/local/bin/x86_64-intelmic-linux-gnu-g++ manually, it can find cc1plus just fine. Jakub
Re: Offloading not relocatable
On Wed, Sep 17, 2014 at 06:11:25PM +0200, Jakub Jelinek wrote:
> On Wed, Sep 17, 2014 at 04:21:42PM +0200, Jakub Jelinek wrote:
> > >From -v dump, that sounds like a bug in mkoffload, which has been found
> > properly relatively to the gcc driver or whatever.
> >
> > /usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload
> > @/tmp/ccS6Q83l
> > collect2: error trying to exec
> > '/usr/local/bin/x86_64-intelmic-linux-gnu-g++': execvp: No such file or
> > directory
> > lto-wrapper: fatal error:
> > /usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload
> > terminated with signal 11 [Segmentation fault], core dumped
> > compilation terminated.
> > /usr/bin/ld: lto-wrapper failed
> > collect2: error: ld returned 1 exit status
> >
>
> In the same setup, I've added (as root)
> #!/bin/sh
> exec /usr/src/gcc-git/objinst/usr/local/bin/x86_64-intelmic-linux-gnu-g++ "$@"
> script to /usr/local/bin/x86_64-intelmic-linux-gnu-g++ .
> But things don't work in that case either, the error is now:
> /usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload
> @/tmp/cc0nIjXd
> x86_64-intelmic-linux-gnu-g++: error trying to exec 'cc1plus': execvp: No
> such file or directory
> lto-wrapper: fatal error:
> /usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload
> terminated with signal 11 [Segmentation fault], core dumped
> compilation terminated.
> /usr/bin/ld: lto-wrapper failed
> collect2: error: ld returned 1 exit status
>
> which presumably means that some undesirable vars from host environment
> were kept by mkoffload in the environment for the offloading compiler
> and that has the undesirable effect of affecting how the offloading
> compiler driver works. Because, if I invoke
> /usr/local/bin/x86_64-intelmic-linux-gnu-g++ manually, it can find cc1plus
> just fine.
unset GCC_EXEC_PREFIX
in the /usr/local/bin/x86_64-intelmic-linux-gnu-g++ script somewhat helps,
presumably mkoffload shouldn't export GCC_EXEC_PREFIX env var when
calling the driver, as it should be driver's business to find everything
else on its own.
/usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload
@/tmp/ccySFivX
x86_64-intelmic-linux-gnu-g++: fatal error: -fuse-linker-plugin, but
liblto_plugin.so not found
compilation terminated.
lto-wrapper: fatal error:
/usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0//accel/x86_64-intelmic-linux-gnu/mkoffload
terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
is the next error though.
find `pwd` -name \*lto\*.so\*
/usr/src/gcc-git/objinst/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/liblto_plugin.so
/usr/src/gcc-git/objinst/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/liblto_plugin.so.0.0.0
/usr/src/gcc-git/objinst/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/liblto_plugin.so.0
/usr/src/gcc-git/objinst/usr/local/libexec/gcc/x86_64-intelmic-linux-gnu/5.0.0/liblto_plugin.so
/usr/src/gcc-git/objinst/usr/local/libexec/gcc/x86_64-intelmic-linux-gnu/5.0.0/liblto_plugin.so.0.0.0
/usr/src/gcc-git/objinst/usr/local/libexec/gcc/x86_64-intelmic-linux-gnu/5.0.0/liblto_plugin.so.0
strace tells me it has searched (far before that the host compiler's lto plugin
has been found
just fine):
[pid 9491]
access("/usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/accel/x86_64-intelmic-linux-gnu/liblto_plugin.so",
R_OK) = -1 ENOENT (No such file or directory)
[pid 9491]
access("/usr/src/gcc-git/objinst/usr/local/bin/../libexec/gcc/liblto_plugin.so",
R_OK) = -1 ENOENT (No such file or directory)
[pid 9491]
access("/usr/local/libexec/gcc/x86_64-intelmic-linux-gnu/5.0.0/x86_64-unknown-linux-gnu/5.0.0/accel/x86_64-intelmic-linux-gnu/liblto_plugin.so",
R_OK) = -1 ENOENT (No such file or directory)
[pid 9491]
access("/usr/local/libexec/gcc/x86_64-intelmic-linux-gnu/5.0.0/liblto_plugin.so",
R_OK) = -1 ENOENT (No such file or directory)
[pid 9491]
access("/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/accel/x86_64-intelmic-linux-gnu/x86_64-unknown-linux-gnu/5.0.0/accel/x86_64-intelmic-linux-gnu/liblto_plugin.so",
R_OK) = -1 ENOENT (No such file or directory)
[pid 9491]
access("/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/accel/x86_64-intelmic-linux-gnu/liblto_plugin.so",
R_OK) = -1 ENOENT (No such file or directory)
[pid 9491]
access("/usr/src/gcc-git/objinst/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.0.0/accel/x86_64-intelmic-linux-gnu/../../../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/5.0.0/accel/x86_64-in
Re: Offloading not relocatable
On 09/17/2014 06:22 PM, Jakub Jelinek wrote:
which presumably means that some undesirable vars from host environment
were kept by mkoffload in the environment for the offloading compiler
and that has the undesirable effect of affecting how the offloading
compiler driver works. Because, if I invoke
/usr/local/bin/x86_64-intelmic-linux-gnu-g++ manually, it can find cc1plus
just fine.
unset GCC_EXEC_PREFIX
in the /usr/local/bin/x86_64-intelmic-linux-gnu-g++ script somewhat helps,
presumably mkoffload shouldn't export GCC_EXEC_PREFIX env var when
calling the driver, as it should be driver's business to find everything
else on its own.
That's also a solved problem in nvptx mkoffload - you do need to unset
these environment variables when invoking the target compiler. I've
posted the source a few times but here it is again.
Bernd
/* Offload image generation tool for ptx
Nathan Sidwell
Bernd Schmidt
Munges PTX assembly into a C source file defining the PTX code as a
string.
This is not a complete assembler. We presume the source is well
formed from the compiler and can die horribly if it is not. */
#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "intl.h"
#include
#include "obstack.h"
#include "diagnostic-core.h"
#include "collect-utils.h"
const char tool_name[] = "nvptx mkoffload";
#define COMMENT_PREFIX "#"
typedef enum Kind
{
/* 0-ff used for single char tokens */
K_symbol = 0x100, /* a symbol */
K_label, /* a label defn (i.e. symbol:) */
K_ident, /* other ident */
K_dotted, /* dotted identifier */
K_number,
K_string,
K_comment
} Kind;
typedef struct Token
{
unsigned short kind : 12;
unsigned short space : 1; /* preceded by space */
unsigned short end : 1; /* succeeded by end of line */
/* Length of token */
unsigned short len;
/* Token itself */
char const *ptr;
} Token;
/* statement info */
typedef enum Vis
{
V_dot = 0, /* random pseudo */
V_var = 1, /* var decl/defn */
V_func = 2, /* func decl/defn */
V_insn = 3, /* random insn */
V_label = 4, /* label defn */
V_comment = 5,
V_pred = 6, /* predicate */
V_mask = 0x7,
V_global = 0x08, /* globalize */
V_weak = 0x10, /* weakly globalize */
V_no_eol = 0x20, /* no end of line */
V_prefix_comment = 0x40 /* prefixed comment */
} Vis;
typedef struct Stmt
{
struct Stmt *next;
Token *tokens;
unsigned char vis;
unsigned len : 12;
unsigned sym : 12;
} Stmt;
struct id_map
{
id_map *next;
char *ptx_name;
};
static const char *read_file (FILE *);
static Token *tokenize (const char *);
static void write_token (FILE *, const Token *);
static void write_tokens (FILE *, const Token *, unsigned, int);
static Stmt *alloc_stmt (unsigned, Token *, Token *, const Token *);
#define alloc_comment(S,E) alloc_stmt (V_comment, S, E, 0)
#define append_stmt(V, S) ((S)->next = *(V), *(V) = (S))
static Stmt *rev_stmts (Stmt *);
static void write_stmt (FILE *, const Stmt *);
static void write_stmts (FILE *, const Stmt *);
static Token *parse_insn (Token *);
static Token *parse_list_nosemi (Token *);
static Token *parse_init (Token *);
static Token *parse_file (Token *);
static Stmt *decls;
static Stmt *vars;
static Stmt *fns;
static id_map *func_ids, **funcs_tail = &func_ids;
static id_map *var_ids, **vars_tail = &var_ids;
/* Files to unlink. */
static const char *ptx_name;
static const char *ptx_cfile_name;
/* Delete tempfiles. */
/* Unlink a temporary file unless requested otherwise. */
void
maybe_unlink (const char *file)
{
if (! debug)
{
if (unlink_if_ordinary (file)
&& errno != ENOENT)
fatal_error ("deleting file %s: %m", file);
}
else
fprintf (stderr, "[Leaving %s]\n", file);
}
void
tool_cleanup (bool)
{
}
/* Add or change the value of an environment variable, outputting the
change to standard error if in verbose mode. */
static void
xputenv (const char *string)
{
if (verbose)
fprintf (stderr, "%s\n", string);
putenv (CONST_CAST (char *, string));
}
static void
record_id (const char *p1, id_map ***where)
{
const char *end = strchr (p1, '\n');
if (!end)
fatal_error ("malformed ptx file");
id_map *v = XNEW (id_map);
size_t len = end - p1;
v->ptx_name = XNEWVEC (char, len + 1);
memcpy (v->ptx_name, p1, len);
v->ptx_name[len] = '\0';
v->next = NULL;
id_map **tail = *where;
*tail = v;
*where = &v->next;
}
/* Read the whole input file. It will be NUL terminated (but
remember, there could be a NUL in the file itself. */
static const char *
read_file (FILE *stream)
{
size_t alloc = 16384;
size_t base = 0;
char *buffer;
if (!fseek (stream, 0, SEEK_END))
{
/* Get the file size. */
long s = ftell (stream);
if (s >= 0)
alloc = s + 100;
fseek (stream, 0, SEEK_SET);
}
buffer = XNEWVEC (char, alloc);
for (;;)
{
size_t n = fread (buffer + base, 1, alloc - base - 1, stream);
if (!n)
Re: Offloading not relocatable
Yeah, I got that all these prefixes are not working with modified
DESTDIR. I’ll fix mkoffload.
2014-09-17 20:30 GMT+04:00 Bernd Schmidt :
> That's also a solved problem in nvptx mkoffload - you do need to unset these
> environment variables when invoking the target compiler. I've posted the
> source a few times but here it is again.
I see there:
unsetenv ("GCC_EXEC_PREFIX");
unsetenv ("COMPILER_PATH");
unsetenv ("LIBRARY_PATH");
Or do you mean, that there is no need to set them to the new values
before invoking the target compiler?
Thanks,
-- Ilya
Re: Offloading not relocatable
On Wed, Sep 17, 2014 at 08:39:38PM +0400, Ilya Verbin wrote:
> 2014-09-17 20:30 GMT+04:00 Bernd Schmidt :
> > That's also a solved problem in nvptx mkoffload - you do need to unset these
> > environment variables when invoking the target compiler. I've posted the
> > source a few times but here it is again.
>
> I see there:
> unsetenv ("GCC_EXEC_PREFIX");
> unsetenv ("COMPILER_PATH");
> unsetenv ("LIBRARY_PATH");
>
> Or do you mean, that there is no need to set them to the new values
> before invoking the target compiler?
If you are invoking the target compiler DRIVER (rather than compiler),
you should not have those in the environment, otherwise those env vars
will override where the target compiler driver would be looking for
the target compiler, libraries, headers etc.
Jakub
Re: Offloading not relocatable
On 09/17/2014 06:39 PM, Ilya Verbin wrote:
Yeah, I got that all these prefixes are not working with modified
DESTDIR. I’ll fix mkoffload.
2014-09-17 20:30 GMT+04:00 Bernd Schmidt :
That's also a solved problem in nvptx mkoffload - you do need to unset these
environment variables when invoking the target compiler. I've posted the
source a few times but here it is again.
I see there:
unsetenv ("GCC_EXEC_PREFIX");
unsetenv ("COMPILER_PATH");
unsetenv ("LIBRARY_PATH");
Or do you mean, that there is no need to set them to the new values
before invoking the target compiler?
Exactly - you need to unset them before calling x86-accel-nvptx-gcc, but
that driver has its own logic to find its binaries, so nothing else is
necessary. You need to know where to find x86-accel-nvptx-gcc, and that
can be done by examining COMPILER_PATH.
Bernd
Fwd: Building gcc-4.9 on OpenBSD
The reason I'm doing this is that I want to understand why the total size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in 4.9 I can compile the first stage OK, and the binaries are quite modest: -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1 -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/cpp -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/xgcc The 2nd stage doesn't compile however, because the Intel library doesn't support OpenBSD. The host/target is i386-unknown-openbsd5.4: ../.././libcilkrts/runtime/os-unix.c:69:5: error: #error "Unsupported OS" # error "Unsupported OS" ^ ../.././libcilkrts/runtime/os-unix.c: In function '__cilkrts_hardware_cpu_count': ../.././libcilkrts/runtime/os-unix.c:386:2: error: #error "Unknown architecture" #error "Unknown architecture" ^ Makefile:691: recipe for target 'os-unix.lo' failed My questions are, is this what I should expect in terms of file sizes?: ian3@jaguar:~/build/guile-2.0.11$ ls -l ~/usr/bin/gcc ~/usr/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1 -rwxr-xr-x 3 ian3 ian3 2538426 2014-08-03 01:18 /home/ian3/usr/bin/gcc -rwxr-xr-x 1 ian3 ian3 66149541 2014-08-03 01:18 /home/ian3/usr/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1 ian3@jaguar:~/build/guile-2.0.11$ And is there any way to disable the Intel library? The fact that the first stage bootstrap works without it indicates that it might be possible. Thanks Ian
Fwd: Building gcc-4.9 on OpenBSD
The reason I'm doing this is that I want to understand why the total size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in 4.9 I can compile the first stage OK, and the binaries are quite modest: -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1 -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/cpp -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/xgcc The 2nd stage doesn't compile however, because the Intel library doesn't support OpenBSD. The host/target is i386-unknown-openbsd5.4: ../.././libcilkrts/runtime/os-unix.c:69:5: error: #error "Unsupported OS" # error "Unsupported OS" ^ ../.././libcilkrts/runtime/os-unix.c: In function '__cilkrts_hardware_cpu_count': ../.././libcilkrts/runtime/os-unix.c:386:2: error: #error "Unknown architecture" #error "Unknown architecture" ^ Makefile:691: recipe for target 'os-unix.lo' failed My questions are, is this what I should expect in terms of file sizes?: ian3@jaguar:~/build/guile-2.0.11$ ls -l ~/usr/bin/gcc ~/usr/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1 -rwxr-xr-x 3 ian3 ian3 2538426 2014-08-03 01:18 /home/ian3/usr/bin/gcc -rwxr-xr-x 1 ian3 ian3 66149541 2014-08-03 01:18 /home/ian3/usr/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1 ian3@jaguar:~/build/guile-2.0.11$ And is there any way to disable the Intel library? The fact that the first stage bootstrap works without it indicates that it might be possible. Thanks Ian
Re: Fwd: Building gcc-4.9 on OpenBSD
On Wed, 17 Sep 2014, Ian Grant wrote: And is there any way to disable the Intel library? --disable-libcilkrts (same as the other libs) If it explicitly doesn't support your system, I am a bit surprised it isn't disabled automatically, that seems like a bug. Please don't call it "the Intel library", that doesn't mean anything. -- Marc Glisse
Re: Fwd: Building gcc-4.9 on OpenBSD
On Wed, Sep 17, 2014 at 1:36 PM, Marc Glisse wrote: > On Wed, 17 Sep 2014, Ian Grant wrote: > >> And is there any way to disable the Intel library? > --disable-libcilkrts (same as the other libs) > If it explicitly doesn't support your system, I am a bit surprised it isn't > disabled automatically, that seems like a bug. Not necessarily a bug, but it would have been good if the --help option had mentioned it. I looked, really. Perhaps I missed it though. So many options for disabling one thing or another > Please don't call it "the Intel library", that doesn't mean anything. Doesn't it? How did you know what 'it' was then? Or is that a stupid question? This identity concept is much slipperier than it seems at first, isn't it? How about my question about the size of the binaries? Is that 60+MB what other systems show? What is the extra function 4.9 has over 4.5 to which I'm dedicating 50MB of disk? Warning messages? Ian
Re: Fwd: Building gcc-4.9 on OpenBSD
On Wed, 17 Sep 2014, Ian Grant wrote: On Wed, Sep 17, 2014 at 1:36 PM, Marc Glisse wrote: On Wed, 17 Sep 2014, Ian Grant wrote: And is there any way to disable the Intel library? --disable-libcilkrts (same as the other libs) If it explicitly doesn't support your system, I am a bit surprised it isn't disabled automatically, that seems like a bug. Not necessarily a bug, but it would have been good if the --help option had mentioned it. I looked, really. Perhaps I missed it though. So many options for disabling one thing or another https://gcc.gnu.org/install/configure.html lists a number of others but not this one, maybe it should be added. Please don't call it "the Intel library", that doesn't mean anything. Doesn't it? How did you know what 'it' was then? Or is that a stupid question? This identity concept is much slipperier than it seems at first, isn't it? You included error messages... How about my question about the size of the binaries? Is that 60+MB what other systems show? I still see <20M here, but I don't know if there are reasons for what you are seeing. Are you maybe using different options? (debug information, optimization, lto, etc) -- Marc Glisse
Re: Fwd: Building gcc-4.9 on OpenBSD
On Wed, Sep 17, 2014 at 2:59 PM, Marc Glisse wrote: >>> Please don't call it "the Intel library", that doesn't mean anything. >> Doesn't it? How did you know what 'it' was then? Or is that a stupid >> question? This identity concept is much slipperier than it seems at >> first, isn't it? > You included error messages... Context. And this is what gave that noun meaning. Context is important in semantics. You can't tell what anything, a C compiler binary, for example, means in isolation. >> How about my question about the size of the binaries? Is that 60+MB >> what other systems show? > > I still see <20M here, but I don't know if there are reasons for what you > are seeing. Are you maybe using different options? (debug information, > optimization, lto, etc) That is very useful to know. Thanks. Ian
Re: LLVM collaboration?
Rafael,
As I mentioned earlier on IRC, the current trunk LLVM plugin requires get_view
and get/release_input_file (which had not previously been the case). I've
attached a version of the patch that also provides an implementation of those
functions.
-Hal
- Original Message -
> From: "Hal Finkel"
> To: "Rafael Espíndola"
> Cc: "Renato Golin" , "gcc" , "Jan
> Hubicka"
> Sent: Tuesday, February 11, 2014 4:35:59 PM
> Subject: Re: LLVM collaboration?
>
> - Original Message -
> > From: "Rafael Espíndola"
> > To: "Jan Hubicka"
> > Cc: "Renato Golin" , "gcc"
> > , "Hal Finkel"
> > Sent: Tuesday, February 11, 2014 3:38:40 PM
> > Subject: Re: Fwd: LLVM collaboration?
> >
> > > My reading of bfd/plugin.c is that it basically walks the
> > > directory
> > > and looks
> > > for first plugin that returns OK for onload. (that is always the
> > > case for
> > > GCC/LLVM plugins). So if I instlal GCC and llvm plugin there it
> > > will
> > > depend who will end up being first and only that plugin will be
> > > used.
> > >
> > > We need multiple plugin support as suggested by the directory
> > > name
> > > ;)
> > >
> > > Also it sems that currently plugin is not used if file is ELF for
> > > ar/nm/ranlib
> > > (as mentioned by Markus) and also GNU-ld seems to choke on LLVM
> > > object files
> > > even if it has plugin.
> > >
> > > This probably needs ot be sanitized.
> >
> > CCing Hal Finkel. He got this to work some time ago. Not sure if he
> > ever ported the patches to bfd trunk.
>
> I have a patch for binutils 2.24 (attached -- I think this works, I
> hand isolated it from my BG/Q patchset). I would not consider it to
> be of upstream quality, but I'd obviously appreciate any assistance
> on making everything clean and proper ;)
>
> -Hal
>
> >
> > >> For OS X the situation is a bit different. There instead of a
> > >> plugin
> > >> the linker loads a library: libLTO.dylib. When doing LTO with a
> > >> newer
> > >> llvm, one needs to set DYLD_LIBRARY_PATH. I think I proposed
> > >> setting
> > >> that from clang some time ago, but I don't remember the outcome.
> > >>
> > >> In theory GCC could implement a libLTO.dylib and set
> > >> DYLD_LIBRARY_PATH. The gold/bfd plugin that LLVM uses is
> > >> basically
> > >> a
> > >> API mapping the other way, so the job would be inverting it. The
> > >> LTO
> > >> model ld64 is a bit more strict about knowing all symbol
> > >> definitions
> > >> and uses (including inline asm), so there would be work to be
> > >> done
> > >> to
> > >> cover that, but the simple cases shouldn't be too hard.
> > >
> > > I would not care that much about symbols in asm definitions to
> > > start with.
> > > Even if we will force users to non-LTO those object files, it
> > > would
> > > be an
> > > improvement over what we have now.
> > >
> > > One problem is that we need a volunteer to implement the reverse
> > > glue
> > > (libLTO->plugin API), since I do not have an OS X box (well, have
> > > an old G5,
> > > but even that is quite far from me right now)
> > >
> > > Why complete symbol tables are required? Can't ld64 be changed to
> > > ignore
> > > unresolved symbols in the first stage just like gold/gnu-ld does?
> >
> > I am not sure about this. My *guess* is that it does dead stripping
> > computation before asking libLTO for the object file. I noticed the
> > issue while trying to LTO firefox some time ago.
> >
> > Cheers,
> > Rafael
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
diff --git a/bfd/elflink.c b/bfd/elflink.c
index 99b7ca1..c2bf9c3 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -5054,7 +5054,9 @@ elf_link_add_archive_symbols (bfd *abfd, struct bfd_link_info *info)
goto error_return;
if (! bfd_check_format (element, bfd_object))
- goto error_return;
+ /* goto error_return; */
+/* this might be an object understood only by an LTO plugin */
+bfd_elf_make_object (element);
/* Doublecheck that we have not included this object
already--it should be impossible, but there may be
diff --git a/ld/ldfile.c b/ld/ldfile.c
index 16baef8..159a60c 100644
--- a/ld/ldfile.c
+++ b/ld/ldfile.c
@@ -38,6 +38,7 @@
#ifdef ENABLE_PLUGINS
#include "plugin-api.h"
#include "plugin.h"
+#include "elf-bfd.h"
#endif /* ENABLE_PLUGINS */
bfd_boolean ldfile_assumed_script = FALSE;
@@ -124,6 +125,7 @@ bfd_boolean
ldfile_try_open_bfd (const char *attempt,
lang_input_statement_type *entry)
{
+ int is_obj = 0;
entry->the_bfd = bfd_openr (attempt, entry->target);
if (verbose)
@@ -168,6 +170,34 @@ ldfile_try_open_bfd (const char *attempt,
{
if (! bfd_check_format (check, bfd_object))
{
+#ifdef ENABLE_PLUGINS
+ if (check == entry->the_bfd
+ && bfd_get_error () == bfd_error_file_not_recognized
gcc-4.9-20140917 is now available
Snapshot gcc-4.9-20140917 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140917/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 215340 You'll find: gcc-4.9-20140917.tar.bz2 Complete GCC MD5=e067ab5fa81e0e77f38c881543601972 SHA1=a9131e558b5e20f42cf9ccf0b1896225019c73d3 Diffs from 4.9-20140910 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
LTO detects violations of one-definition-rule ?
Like this (https://gcc.gnu.org/ml/gcc-testresults/2014-09/msg01374.html): /home/toon/compilers/trunk/gcc/tlink.c:62:16: error: type 'struct file_hash_entry' violates one definition rule [-Werror=odr] typedef struct file_hash_entry ^ /home/toon/compilers/trunk/libcpp/files.c:143:8: note: a different type is defined in another translation unit struct file_hash_entry ^ /home/toon/compilers/trunk/gcc/tlink.c:64:15: note: the first difference of corresponding definitions is field 'key' const char *key; ^ /home/toon/compilers/trunk/libcpp/files.c:145:27: note: a field with different name is defined in another translation unit struct file_hash_entry *next; ^ -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
