[Bug other/63979] New: [openacc] undefined reference to main._omp_fn.x

[Bug other/63979] New: [openacc] undefined reference to main._omp_fn.x

[vries at gcc dot gnu.org]

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

            Bug ID: 63979
           Summary: [openacc] undefined reference to main._omp_fn.x
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org

Created attachment 34041
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34041&action=edit
asyncwait-2.c

When compiling an openacc test-case with the gomp-4_0-branch, I run into:
...
$ ./lean-c/install/bin/gcc asyncwait-2.c -fopenacc -flto --param
lto-min-partition=900
/tmp/ccRhKrwN.ltrans0.ltrans.o:(__gnu_offload_funcs+0x0): undefined reference
to `main._omp_fn.20'
/tmp/ccRhKrwN.ltrans0.ltrans.o:(__gnu_offload_funcs+0x8): undefined reference
to `main._omp_fn.19'
/tmp/ccRhKrwN.ltrans1.ltrans.o: In function `main':
ccRhKrwN.ltrans1.o:(.text+0xe19): undefined reference to `cuStreamCreate'
collect2: error: ld returned 1 exit status
...

Note that I'm using patch
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00085.html on top of
gomp-4_0-branch, otherwise any openacc testcase will fail in lto when
processing openacc builtins.

[Bug other/63979] [openacc] undefined reference to main._omp_fn.x

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
I only run into this with -flto-partition=balanced.

>From the exe.wpa.000i.cgraph dump:
...
Total unit size: 2034, partition size: 1000
Step 0: added main._omp_fn.0/24, size 22, cost 1/0 best 1/0, step 0
Step 1: added main._omp_fn.1/23, size 44, cost 2/0 best 2/0, step 1
  ...
Step 17: added main._omp_fn.17/7, size 694, cost 18/0 best 18/0, step 17
Step 18: added main._omp_fn.18/6, size 735, cost 19/0 best 19/0, step 18
Step 19: added main._omp_fn.19/5, size 775, cost 20/0 best 19/0, step 18
Step 20: added main._omp_fn.20/4, size 816, cost 21/0 best 19/0, step 18
Step 21: added main/3, size 2034, cost 53/21 best 19/0, step 18
Unwinding 3 insertions to step 18
New partition
Step 19: added main._omp_fn.19/5, size 40, cost 1/21 best 1/21, step 19
Step 20: added main._omp_fn.20/4, size 81, cost 2/21 best 2/21, step 20
Step 21: added main/3, size 1299, cost 72/23 best 2/21, step 20
Privatizing symbol name: main._omp_fn.0 -> main._omp_fn.0.lto_priv.0
Promoting as hidden: main._omp_fn.0
Privatizing symbol name: main._omp_fn.1 -> main._omp_fn.1.lto_priv.1
Promoting as hidden: main._omp_fn.1
...

In .exe.ltrans0.s, main._omp_fn.18 is privatized, but exported as global
hidden:
...
        .text
        .globl  main._omp_fn.18.lto_priv.18
        .hidden main._omp_fn.18.lto_priv.18
        .type   main._omp_fn.18.lto_priv.18, @function
main._omp_fn.18.lto_priv.18:
...

In .exe.ltrans1.s, it is referenced, and declared as hidden:
...
        .hidden main._omp_fn.18.lto_priv.18
...

Conversely, in .exe.ltrans1.s, main._omp_fn.20 is not privatized:
...
        .type   main._omp_fn.20, @function
main._omp_fn.20:
...

But in .exe.ltrans0.s, main._omp_fn.20 is referenced, and not declared:
...
.omp_func_table.4851:
        .quad   main._omp_fn.20
...

[Bug other/63979] [openacc] undefined reference to main._omp_fn.x

[iverbin at gmail dot com]

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

--- Comment #2 from Ilya Verbin <iverbin at gmail dot com> ---
I tried to reproduce this issue using trunk gcc and OpenMP:

gcc -fopenmp -flto -flto-partition=balanced -lgfortran -save-temps
libgomp/testsuite/libgomp.fortran/target2.f90

But all functions are privatized, e.g. __target2_MOD_foo._omp_fn.3.lto_priv.5,
it's exported as global hidden in partition 1, and referenced in the offload
table in partition 0 as it was planned.

We should figure out why in your case main._omp_fn.19 and main._omp_fn.20 were
not marked as global...

[Bug other/63979] [openacc] undefined reference to main._omp_fn.x

[bernds at gcc dot gnu.org]

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

--- Comment #3 from Bernd Schmidt <bernds at gcc dot gnu.org> ---
Can you reproduce this with the trunk patch kit I posted internally?
gomp-4_0-branch is somewhat out of date wrt offloading.

[Bug other/63979] [openacc] undefined reference to main._omp_fn.x

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
> Can you reproduce this with the trunk patch kit I posted internally?
> gomp-4_0-branch is somewhat out of date wrt offloading.

No, it does not reproduce that way.

The split falls somewhat differently:
...
Total unit size: 1929, partition size: 900
Step 0: added main._omp_fn.20/24, size 37, cost 1/0 best 1/0, step 0
Step 1: added main._omp_fn.19/23, size 73, cost 2/0 best 2/0, step 1
Step 2: added main._omp_fn.18/22, size 110, cost 3/0 best 3/0, step 2
  ...
Step 17: added main._omp_fn.3/7, size 660, cost 18/0 best 18/0, step 17
Step 18: added main._omp_fn.2/6, size 696, cost 19/0 best 18/0, step 17
Step 19: added main._omp_fn.1/5, size 714, cost 20/0 best 18/0, step 17
Step 20: added main._omp_fn.0/4, size 732, cost 21/0 best 18/0, step 17
Step 21: added main/3, size 1929, cost 53/21 best 18/0, step 17
Unwinding 4 insertions to step 17
New partition
Step 18: added main._omp_fn.2/6, size 36, cost 1/21 best 1/21, step 18
Step 19: added main._omp_fn.1/5, size 54, cost 2/21 best 2/21, step 19
Step 20: added main._omp_fn.0/4, size 72, cost 3/21 best 3/21, step 20
Step 21: added main/3, size 1269, cost 71/24 best 3/21, step 20
...

But I think the main difference is that the offload table and main (using the
offload table) are now in the same partition. I don't know whether that's by
design or accident.

[Bug other/63979] [openacc] undefined reference to main._omp_fn.x

[iverbin at gmail dot com]

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

--- Comment #5 from Ilya Verbin <iverbin at gmail dot com> ---
(In reply to vries from comment #4)
> But I think the main difference is that the offload table and main (using
> the offload table) are now in the same partition. I don't know whether
> that's by design or accident.

What do you mean by "main (using the offload table)"?
The design was to have the offload table in the first partition (number zero),
and the table should be used only in libgomp through the GOMP_offload_register
function.

[Bug other/63979] [openacc] undefined reference to main._omp_fn.x

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
Created attachment 34058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34058&action=edit
ltrans0.s

[Bug other/63979] [openacc] undefined reference to main._omp_fn.x

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
Created attachment 34059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34059&action=edit
ltrans1.s

[Bug other/63979] [openacc] undefined reference to main._omp_fn.x

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
(In reply to Ilya Verbin from comment #5)
> (In reply to vries from comment #4)
> > But I think the main difference is that the offload table and main (using
> > the offload table) are now in the same partition. I don't know whether
> > that's by design or accident.
> 
> What do you mean by "main (using the offload table)"?
> The design was to have the offload table in the first partition (number
> zero),

It seems to be in partition 1:
...
$ grep -c OFFLOAD_TABLE ltrans1.s ltrans0.s 
ltrans1.s:33
ltrans0.s:0
...

> and the table should be used only in libgomp through the
> GOMP_offload_register function.

It's used like this, in main:
...
    movl    $__OFFLOAD_TABLE__, %esi
...

[Bug other/63979] [openacc] undefined reference to main._omp_fn.x

[iverbin at gmail dot com]

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

--- Comment #9 from Ilya Verbin <iverbin at gmail dot com> ---
(In reply to vries from comment #8)
> (In reply to Ilya Verbin from comment #5)
> > (In reply to vries from comment #4)
> > > But I think the main difference is that the offload table and main (using
> > > the offload table) are now in the same partition. I don't know whether
> > > that's by design or accident.
> > What do you mean by "main (using the offload table)"?
> It's used like this, in main:
> 	movl	$__OFFLOAD_TABLE__, %esi

Ah, I see, this is something OpenACC specific, for some reason it passes
__OFFLOAD_TABLE__ to all functions.
Anyway, this is just a weak symbol, which points to the start of the offload
table. It's defined by mkoffload when all partitions are ready. I don't think
that it could somehow affect the LTO partitioning and the functions'
visibility.
>From gcc-bugs-return-467865-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 20 23:56:19 2014
Return-Path: <gcc-bugs-return-467865-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19049 invoked by alias); 20 Nov 2014 23:56:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19023 invoked by uid 48); 20 Nov 2014 23:56:15 -0000
From: "jtaylor.debian at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/64006] New: __builtin_mul_overflow fails to signal overflow
Date: Thu, 20 Nov 2014 23:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jtaylor.debian at googlemail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-64006-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg02337.txt.bz2
Content-length: 2138

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd006

            Bug ID: 64006
           Summary: __builtin_mul_overflow fails to signal overflow
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jtaylor.debian at googlemail dot com

following code does not print overflow while the result does clearly overflow:

$ cat test.c
#include <stdio.h>

int __attribute__((noinline)) wrapper(long a, long b, long * r)
{
return __builtin_mul_overflow(a, b, r);
}

long __attribute__((noinline)) test(long *dims, int nd)
{
    int i;
    long size = 1;
    for (i = 0; i < nd; i++) {
        long dim = dims[i];

        if (__builtin_mul_overflow(size, dim, &size)) {
        //if (wrapper(size, dim, &size)) {
            puts("overflow");
        }
    }
    return size;
}


int main(int argc, char * argv[])
{
    long r;
    long dim[7] = {975,975,975,975,975,975,975};
    r = test(dim, 7);
    printf("%ld\n",r);
}

$ gcc-5.0 -O2 test.c
$ ./a.out
7488110182826036655


if one uses the commented wrapper function version it correctly prints
overflow.


$ gcc-5.0 --version
gcc (GCC) 5.0.0 20141119 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-5.0 -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/media/jtaylor/45d3164a-104c-4489-9021-091002eb6730/data/local-5.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
/media/jtaylor/45d3164a-104c-4489-9021-091002eb6730/data/gcc/configure
--disable-werror --enable-languages=c,c++,fortran --enable-tls
--prefix=/media/jtaylor/45d3164a-104c-4489-9021-091002eb6730/data//gcc/local-5.0
--with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr --with-cloog=/usr
--with-ppl=/usr --with-isl=/usr --disable-bootstrap
Thread model: posix
gcc version 5.0.0 20141119 (experimental) (GCC)