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
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 d
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/
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-intel
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-inte
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/l
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 inv
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
> sou
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
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 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.2
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.2
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 l
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 automaticall
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 surpris
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 in
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:
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
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
19 matches
Mail list logo
