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 B8EF33858D1E; Thu, 11 May 2023 21:17:36 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B8EF33858D1E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1683839856;
	bh=7EjNKnuIcL+ZipJkqTRIEskQeAvLPKDyvh9pYCM74p4=;
	h=From:To:Subject:Date:From;
	b=x0mBiBQ8dLgpQTRvLU2xMj95OWf6dC+/opZwt9572+vJUmtv1/hOSyj8FTO/cvvMP
	 CazHToj14PhaQU1WWODvrhK86tWp20ZD9AGCc01C3Brl9FkkbAjUJ4FbX61xO8nVoA
	 H+KN92coc/aUdOt02SXAUzzlWERC90+FcIa568n8=
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/109819] New: [OpenMP][OpenACC] -fno-lto effectively
 disables offloading
Date: Thu, 11 May 2023 21:17:36 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: openacc, openmp
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus 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: bug_id short_desc product version bug_status
 keywords bug_severity priority component assigned_to reporter cc
 target_milestone
Message-ID: <bug-109819-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
List-Id: <gcc-bugs.sourceware.org>

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

            Bug ID: 109819
           Summary: [OpenMP][OpenACC] -fno-lto effectively disables
                    offloading
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: openacc, openmp
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

In terms of LTO, the idea is for the link time:
If there is -flto =E2=86=92 we know that we should do LTO and, hence, need =
to check
whether there is some. Without -flto, it might be that there is LTO and with
slim LTO, we may have to handle it.

For that reason, we have the following code in collect2.cc:

#ifdef ENABLE_LTO
static enum lto_mode_d lto_mode =3D LTO_MODE_WHOPR;
#else
static enum lto_mode_d lto_mode =3D LTO_MODE_NONE;
#endif
...
        else if (startswith (argv[i], "-fno-lto"))
          lto_mode =3D LTO_MODE_NONE;
...
    if (use_plugin)
      lto_mode =3D LTO_MODE_NONE;
    if (no_partition && lto_mode =3D=3D LTO_MODE_WHOPR)
      lto_mode =3D LTO_MODE_LTO;


However, this has the unintended side effect that "-fno-lto" also disables
handling the device side of offloading.

* * *

The question is how to handle this. Maybe something along the lines of the
following:


 if (ENABLE_OFFLOADING && lto_mode =3D=3D LTO_MODE_NONE
     && (-fopenmp || -fopenacc) && !-foffload=3Ddisable)
   lto_mode =3D LTO_MODE_WHOPR;=