public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "blubban at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/102198] New: Unused and nonsensical template instantiations used for return type inference end up in the output
Date: Fri, 03 Sep 2021 21:52:46 +0000	[thread overview]
Message-ID: <bug-102198-4@http.gcc.gnu.org/bugzilla/> (raw)

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

            Bug ID: 102198
           Summary: Unused and nonsensical template instantiations used
                    for return type inference end up in the output
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: blubban at gmail dot com
  Target Milestone: ---

Input:

template<int* x>
int* a() { return x; }

template<int* x>
auto b() { return a<x>; }

template<bool q>
auto c() -> int* (*)()
{
    static int x1;
    return b<&x1>();
}

int main(int argc, char** argv)
{
    if constexpr (false)
    {
        static int x2;
        b<&x2>();
    }
    c<true>();
    c<false>();
}

Compile with -O0.

Expected output: Compiles and links successfully.

Actual output, as of 7.2 through 11.2: Assembly output contains four
instantiations of a(), using template arguments c<true>::x1, c<false>::x1,
main::x2, and c<template argument 1>::x1 (or whatever _ZZ1cIXT_EEPFPivEvE2x1 is
supposed to be, c++filt doesn't like it). There's no storage assigned for the
latter two, so they instantiations throw linker errors.

/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../x86_64-linux-gnu/bin/ld:
/tmp/cc2i7eNg.o: in function `_Z1aIXadL_ZZ1cIXT_EEPFPivEvE2x1EEES1_v':
<source>:2: undefined reference to `_ZZ1cIXT_EEPFPivEvE2x1'
/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../x86_64-linux-gnu/bin/ld:
/tmp/cc2i7eNg.o: in function `int* a<&(main::x2)>()':
<source>:2: undefined reference to `main::x2'
collect2: error: ld returned 1 exit status

Actual output, as of current trunk:

<source>: In instantiation of 'auto b() [with int* x = (& x1)]':
<source>:5:6:   required from here
<source>:5:6: internal compiler error: in discriminator_for_local_entity, at
cp/mangle.c:1965
    5 | auto b() { return a<x>; }
      |      ^
0x1f31a39 internal_error(char const*, ...)
        ???:0
0x79e1c7 fancy_abort(char const*, int, char const*)
        ???:0
0x8fe32b mangle_decl(tree_node*)
        ???:0
0x148f6b2 decl_assembler_name(tree_node*)
        ???:0
0x14c15d0 assign_assembler_name_if_needed(tree_node*)
        ???:0
0xc38855 cgraph_node::analyze()
        ???:0
0xc3cfdd symbol_table::finalize_compilation_unit()
        ???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

The issues go away if I change main to  if constexpr (true)  or remove the
template from c(), if I put x1 and x2 in global scope, if I append  -> int*
(*)()  to b(), or if I enable -O1 or higher. Only the template variant gives
ICE,  if constexpr (false)  gives the same bad output in trunk as in 11.2
(after removing or neutralizing c()).

I don't know how many different issues this is, but they all look like
different facets of the same root cause (either the extra a() instantiations
should be discarded after determining b's return type, or they shouldn't be
created at all), so I'm filing one bug for them all.

Compiler Explorer: https://godbolt.org/z/89794xb8v

             reply	other threads:[~2021-09-03 21:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03 21:52 blubban at gmail dot com [this message]
2021-10-06 13:29 ` [Bug c++/102198] " ppalka at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-102198-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).