From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 10062388F07A; Wed, 10 Jun 2020 09:18:57 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 10062388F07A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1591780737;
 bh=HW5CWDnSRwWDFLrmo88JC46nycC36k5usCYyeDovVS4=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=dE2Sje3iUwWDU27FCMDpr2SvCfFSSVHW92mtEEe729vCp4c99F+wsYeFX21ryeVY3
 ET45VWuMc2xuJ8POi4Ezz5hIQaq8VJmeO0tWwa0WP9e5xdQJDuvEa0jhpXHOb7dd5t
 /GcEMD2tac2OLwtBQ0YyADY/2ZvrOMvKduyYou54=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/95622] force_output flag on a variable prevents
 optimization  / regresses c-c++-common/goacc/kernels-alias-ipa-pta-2.c
Date: Wed, 10 Jun 2020 09:18:56 +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: 10.0
X-Bugzilla-Keywords: missed-optimization, openacc, openmp
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: cc
Message-ID: <bug-95622-4-oOtr89pAmu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-95622-4@http.gcc.gnu.org/bugzilla/>
References: <bug-95622-4@http.gcc.gnu.org/bugzilla/>
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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2020 09:18:57 -0000

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Dunno, perhaps there is a better way than force_output, how exactly we
represent
void *refs[] __attribute__((used)) =3D { &var1, &var2, &var3 };
where we say the array can't be optimized away and thus the referenced vars
can't be optimized away?  Does that also prevent such an optimization?
For these vars, all we want to ensure is that the vars aren't optimized awa=
y,
but don't need to derive from that that some other code could be accessing
those vars indirectly.
Or, shall we support putting NULL (or some other magic value) into the tabl=
es
on the host or offload side if those vars have been optimized away complete=
ly
on the host (or offload) sides?  At least when not doing the not yet suppor=
ted
offloading from offload device back to host, perhaps a variable optimized a=
way
completely on the host will mean we can't every lookup such variable's addr=
ess
and so nothing needs to be recorded in the splay trees.  But, if something =
is
completely unused on the offload side but used on the host side, one can st=
ill
try to e.g. map those variables and should get the address of the device var
even if it is otherwise unused.=