https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116535
Bug ID: 116535
Summary: LTO partitioning vs. offloading compilation
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: openacc, openmp, wrong-code
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, hubicka at gcc dot gnu.org,
jakub at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
I ran into a curious issue re LTO partitioning vs. offloading compilation. I
guess what happened was that, given sufficiently high 'make -j', and only
'check-target-libgomp' running (which limits itself to 19 parallel slots), for
the '-flto -flto-partition=max' test cases
'libgomp.oacc-c-c++-common/data-clauses-{kernels,parallel}-ipa-pta.c', there
was actual parallel LTO compilation/partitioning, and these test cases then
FAIL, for example:
libgomp: Cannot map target functions or variables (expected 180 + 0 + 1,
have 11)
Running the compilation outside of 'make -j check', we see:
lto-wrapper: warning: using serial compilation of 36 LTRANS jobs
lto-wrapper: note: see the ‘-flto’ option documentation for more
information
..., and they execute successfully. However, for example, with '-flto=3
-flto-partition=max':
libgomp: Cannot map target functions or variables (expected 30 + 0 + 1,
have 11)
... where here '30' is 'N * 10' for '-flto=N'. So the "expected" number is
wrong.
This reproduces down to GCC 10:
libgomp: Cannot map target functions or variables (expected 30, have 10)
(..., so isn't related to the PR116361 LTO plugin changes.)
