Bug 94320 - [OpenMP][Offloading] lto1 ICE during IPA pass: inline – offline_size at gcc/ipa-inline-analysis.c:453
Summary: [OpenMP][Offloading] lto1 ICE during IPA pass: inline – offline_size at gcc/i...
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: 10.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, openmp
Depends on:
Blocks:
 
Reported: 2020-03-25 11:26 UTC by Tobias Burnus
Modified: 2020-03-26 09:50 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2020-03-25 11:26:03 UTC
May or may not be related to PR 92029

Still reducing the test case. When compiling with "-fopenmp -O0" it works, but with "-fopenmp -O1" the offloading-compiler (AMDGCN or – has here – nvptx) ICEs with:


during IPA pass: inline
lto1: internal compiler error: Segmentation fault
0xbdb6ff crash_signal
        /net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/toplev.c:328
0x98074f offline_size
        /net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline-analysis.c:453
0x980b58 growth_positive_p(cgraph_node*, cgraph_edge*, int)
        /net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline-analysis.c:549
0x138610f want_inline_function_to_all_callers_p
        /net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline.c:1088
0x138c37f ipa_inline
        /net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline.c:2752
0x138d099 execute
        /net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline.c:3091


It fails in ipa-inline-analysis.c's:

offline_size (struct cgraph_node *node, ipa_size_summary *info)
{
  if (!DECL_EXTERNAL (node->decl))
    {
      if (node->will_be_removed_from_program_if_no_direct_calls_p ())
        return info->size;

as info == NULL and decl is " <function_decl 0x7ffff73df500 __ct_base "

"info" is:
    ipa_size_summary *s = ipa_size_summaries->get (node);

And ->get returns:
369         return exists (node) ? (*m_vector)[node->get_summary_id ()] : NULL;
Comment 1 Jakub Jelinek 2020-03-25 11:39:58 UTC
Perhaps related to PR92357?
I'm stuck there, tried
2020-02-07  Jakub Jelinek  <jakub@redhat.com>

        PR ipa/92357
        * symtab.c (symtab_node::get_partitioning_class): Don't return
        SYMBOL_DUPLICATE for DECL_ONE_ONLY symbols if lto_stream_offload_p.

--- gcc/symtab.c.jj     2020-01-15 11:05:19.589136168 +0100
+++ gcc/symtab.c        2020-02-07 19:57:55.625108414 +0100
@@ -2003,6 +2003,7 @@ symtab_node::get_partitioning_class (voi
   if (DECL_ONE_ONLY (decl)
       && !force_output
       && !forced_by_abi
+      && !lto_stream_offload_p
       && !used_from_object_file_p ())
     return SYMBOL_DUPLICATE;

but it didn't work out.  I'm afraid we need to actually implement properly the OpenMP 5.0 automatic omp declare target discovery and before IPA run perhaps another iteration of that and make sure that if we offload something, we either offload everything it refers to too (unless DECL_EXTERNAL), or diagnose it.
Comment 2 Tobias Burnus 2020-03-26 09:50:04 UTC
(In reply to Jakub Jelinek from comment #1)
> tried
> +      && !lto_stream_offload_p

With that patch, I get 6 times "has been referenced in offloaded code but hasn't been marked to be included in the offloaded code".

Thus, that's a useful patch for the code I looked at. All those those functions are template functions. (With -O0, the nvptx run-time compilers complains only about 3 of those functions.)

> I'm afraid we need to actually implement properly the OpenMP 5.0
> automatic omp declare target discovery

Yes, it looks like that. I think C++ code is mostly affected as one quickly ends up using 'operator[]' and similar functions, which are not always inlined.

Additionally, template programming makes it harder for the user to mark those functions as 'declare target'.