From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 90E453858298; Thu, 30 Mar 2023 19:12:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 90E453858298 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1680203575; bh=H17S70VCE4iiugfQu2uiZirqgUfVNMssEhjvsDXB1Xw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EoQObrvgC6qyJENXRJFp/RxMkUCUyO58l3xjXh5VlRJLH9qI+SdSMQGNr0Xkl67r3 t/QUg5xrWDQAbOU+ps12nGnL2Khz07WcWFqnVx7RAIMqP7WEcUw4uo/rngY7+yx9Mc 4xtgsC7ZNGiP8vdQI2196LIoRDau1OCsvBb/W5XQ= From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/109128] [Offload][OpenMP][OpenACC] Static linking with unused offload function will lead to mismatch number of offload fn/symbols Date: Thu, 30 Mar 2023 19:12:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: openacc, openmp, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: 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: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109128 --- Comment #4 from Tobias Burnus --- Minor observations (unrelated to this bug but should be fixed. separately or together): - '@' file in lto-wrapper.cc's compile_offload_image's fork_execute call is always the same. (Matters if there is more than one offloading target configured) - The sections ".gnu.offload_funcs" and ".gnu.offload_vars" are 'wx' but th= ey could be 'x' (i.e. read only as the function addresses do not need to be written to). =E2=86=92 TREE_READONLY (funcs_decl) =3D 1; (same for 'vars_de= cl'). * * * Tried the following, but it did not help =E2=80=93 'ld' does not import any= symbol from the 'libone.a' library =E2=80=93 neither before nor after the patch; not did -no-as-needed help and -Wl,--print-gc-sections does not show any discarded sections. diff --git a/gcc/omp-offload.cc b/gcc/omp-offload.cc index 3bd144e9ccf..e1b22729994 100644 --- a/gcc/omp-offload.cc +++ b/gcc/omp-offload.cc @@ -437,0 +438,13 @@ omp_finish_file (void) + TREE_READONLY (funcs_decl) =3D 1; + TREE_READONLY (vars_decl) =3D 1; +#ifndef ACCEL_COMPILER + if (SUPPORTS_SHF_GNU_RETAIN) + { + DECL_ATTRIBUTES (funcs_decl) =3D tree_cons (get_identifier ("reta= in"), + NULL_TREE, NULL_TREE); + DECL_ATTRIBUTES (vars_decl) =3D tree_cons (get_identifier ("retai= n"), + NULL_TREE, NULL_TREE); + } + else + sorry ("support for % required for offloading"); +#endif diff --git a/libgcc/offloadstuff.c b/libgcc/offloadstuff.c index 4e1c4d41dd5..59e191c5e19 100644 --- a/libgcc/offloadstuff.c +++ b/libgcc/offloadstuff.c @@ -51 +51 @@ const void *const __offload_func_table[0] - __attribute__ ((__used__, visibility ("hidden"), + __attribute__ ((__used__, visibility ("hidden"), retain, @@ -54 +54 @@ const void *const __offload_var_table[0] - __attribute__ ((__used__, visibility ("hidden"), + __attribute__ ((__used__, visibility ("hidden"), retain, @@ -60 +60 @@ const void *const __offload_funcs_end[0] - __attribute__ ((__used__, visibility ("hidden"), + __attribute__ ((__used__, visibility ("hidden"), retrain, @@ -63 +63 @@ const void *const __offload_vars_end[0] - __attribute__ ((__used__, visibility ("hidden"), + __attribute__ ((__used__, visibility ("hidden"), retrain, * * * What's interesting is the file -foffload-objects=3Da.ofldlist - produced by lto-plugin: * If there is a common block in 'one.f90' (and via module use also in 'two.f90'), the a.ofldlist file contains both 'two.o' and the ./libone.a@0x= c0 library. * But if there is no common block in 'one.f90' (and hence also not in 'two.f90'), the a.ofldlist file contains only 'two.o'.=